On 27 Jun 2003 at 11:03, Arje Cahn wrote: > Sorry to interrupt you guys in your discussion. I would like to share > my enthousiasm.
No, no, you're welcome here. The more the merrier! > 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. Yes, I'm happy to separate them - a sitemap component that can be used to build 'site-building-sites' that passes a request on to some other background process. That sounds like a sensible idea (and probably necessary if you've got asynchronous generation). > 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. My aim is to serve the poor (!), if you handle the content-intensive sites, we'll cover a lot of bases! > UH> > Great! We could eventually also supply a way to delete remote > UH> > resources when they no longer exist locally. > > Applause! That and not generating cached pages would be cool. Regards, Upayavira
