> > 1. Have a single Cocoon site (e.g. hosted on a broadband > > connection, or in a companies office) that can publish to > > 'dumb' web servers. Would be extremely useful for 'poorer' > > organisations. > > This is exactly the way we use it at the moment. Not only is it useful > for poorer organisations but the fact that the servers only need to > serve static content improves performance as well. It also helps when > complexity is concentrated at one place.
It would be a great extension to Cocoon to make this work well. > > 2. Have a single Cocoon site that 'syndicates' content to > > other 'dumb' web servers, by sending ready built HTML to > > them. One of my sites has a list of addresses that I would > > like to syndicate to a network of web sites (each paying > > around £60pa for hosting). Their webmasters are not that > > technical, so XML pull syndication will be beyond most of > > them, so sending them a new HTML everytime an address changes > > would be absolutely splendid. > > Great! I'm glad you like it. > > The new (m3) CocoonBean can itself write to > > ModifiableSources, so your web service wouldn't need to worry > > about delivering the file. If someone wrote an FTP source, > > then all you'd need to say is deliver this url > > /folder/page.html to this destination > > ftp://u:[EMAIL PROTECTED]/folder/, and off it goes. All the web > > service needs to do is create the CocoonBean instance and ask > > it to generate. > > The way my implementation works now is that it reuses the Cocoon > instance that also handles HTTP requests. I'm happy with this approach > because it means that apart from the memory that is shared this way, > most of the time resources will already have been cached as well. The > load on the Cocoon servers can get heavy in our situation and > simultaneous publication request can and do happen often meaning that > optimalisation was important when we were designing it. > > So I think I do need to hold on to the idea of using the same Cocoon > instance for publications wich means that if I were to use CocoonBean > I'd also need a way for the HTTP servlet to work with that, or at > least share the Cocoon instance it uses. Is there a way to accomplish > that? I don't see why the bean couldn't be instantiated with a cocoon instance: CocoonBean bean = new CocoonBean(cocoon); or something like that. So long as the bean code can handle both possibilities. > I also noticed that there is some state associated with > CocoonBean that prevents it from being shared among clients. So > although there is a lot of functionality there I'm not sure how to use > it in this multi-threaded multi-client situation. The bean started as (and still pretty much is) a simple separation of the CLI Main.java class into two parts. So it doesn't think at all in terms of multi-threaded environments. However, I don't see why it couldn't be improved. What 'state' are you referring to? > > Look at the code in the Cocoon bean. The Target class does > > offer different ways to help with the decision as to how the > > destinations are generated. It can cater for single files > > being generated, or for whole sites being spidered (even from > > one target). > > > > There's much that could be done on the bean iteself to extend > > its functionality - and this would make it more useful to > > Bean and to CLI users alike. Have you looked at the Target class? Does it seem helpful? I've added info to the wiki (wiki.cocoondev.org/Wiki.jsp?page=CommandLine), see section 7, that explains them a bit more. > I'm glad to help! Great. Upayavira
