Hi again ;)

> 
> Unico,
> 
> Replying to your other mail too:
> 
> > As you all know, there are currently two ways that Cocoon resources 
> > are published: either over http or generated on the command 
> line. The 
> > way we use Cocoon at Hippo seems to be something of a 
> combination of 
> > these two approaches: an http server running an instance of Cocoon 
> > functions as a CMS for content editors and explicit publishing 
> > commands trigger the exportation of resources to a separate live 
> > server that hosts the actual site.
> 
> I had thought of something similar myself too...
>  
> > I was wondering about whether or not this would be 
> something that is 
> > genarally useful for Cocoon either as a block or core component set.
> > And if so I'd like to know what others think would be the best 
> > approach to implement this. I currently see several different 
> > possibilities.
> 
> Let me know your ideas. I can immediately think of uses:
> 
> 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.

> 
> 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.

> 
> > One that we are using at the moment is that of a separate 
> webservice 
> > that creates custom Environments for each resource to be 
> published and 
> > passes it to Cocoon to process. The target can be a local 
> filesystem 
> > or an FTP server. The client interface to this webservice is very 
> > simple but still rather coarse and experimental: the only 
> parameters 
> > are the url of the resource to start publishing at and a max-depth 
> > parameter that is passed to a crawler. The webservice is 
> configured to 
> > map these urls to target locations so that the same system running 
> > several different websites can publish these to separate locations.
> 
> 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 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.

> 
> > In order for me to adapt the code so as to make it most useful to 
> > Cocoon there are several things I would need to decide on. One 
> > concerns the way clients make publication requests. My current 
> > thinking is to trigger the publication of resources by 
> specifying some 
> > special query parameter after the basic url, similar to the 
> way views 
> > are currently requested. Another question is how 
> publication targets 
> > are chosen. One way is to let the client name a pre-configured 
> > publication target to publish to, another is to indicate 
> this in the 
> > sitemap, perhaps by providing suplemental information on a pipeline.
> 
> 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.
> 
> I'd love to have someone helping me on it!


I'm glad to help!

Unico

Reply via email to