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

Reply via email to