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