cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject RE: Cocoon resource publishing
Date Thu, 19 Jun 2003 11:20:34 GMT
> > 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:p@server/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 
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 
(, see section 7, that explains 
them a bit more.

> I'm glad to help!



View raw message