Sorry to interrupt you guys in your discussion. I would like to share my enthousiasm.

UV> there not other examples too? The thing is, that if you 
UV> create a sitemap component, 
UV> you can build around the publishing service a web site for 
UV> deployment. Imagine a site 
UV> that you log onto (e.g. using the authentication framework). 

Yeah! Sounds good!

But personally, I agree with Unico's point that

UH> the role of the sitemap and its components should
UH> be more or less constrained to creating documents.

But then again:

UV> Then, Cocoon reads a database to find out what sites you are allowed to publish, 
UV> and offers you a drop down 
UV> Then you might have a 'status' 
UV> page, based around a 
UV> 'PublishServiceStatusGenerator' that can tell you how it's 
UV> getting on. It allows the site 

Yiihaa! That would be sooo cool.

UV> designer to build a web interface to publish their site. 
UV> That's why I would like to see it 
UV> as a sitemap component, because I would like to use it in 
UV> building sites to build sites!

Damn right! But aren't these two seperate things? One is running the publishing 
mechanism in the background and the other one (a sitemap component) is controlling it 
and retrieving status information.

UV> For poor people, they can stick the Cocoon site on an ADSL 
UV> line, and have it publish 
UV> to a proper web server. Multiple authors can upload content 
UV> and publish it, and the 
UV> world sees a decent web server.

Not only for the poor - it is also a major performance improvement for 
content-intensive sites (the ones we build ;-) ). I believe that one should publish 
everything that is as-good-as static as soon as it has been changed (ie flushed out of 
the cache?). This lowers the database retrieval overhead for big sites. By the way, 
you don't need to publish complete HTML pages; you could publish XML documents as well 
(back to the same Cocoon instance). For example, the result of a major query on the 
database that takes a long to generate. 

UH> > Great! We could eventually also supply a way to delete remote
UH> > resources when they no longer exist locally.

Applause!

Thanks.

Arje

Reply via email to