cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira" ...@upaya.co.uk>
Subject RE: Cocoon resource publishing
Date Fri, 27 Jun 2003 09:23:58 GMT
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



Mime
View raw message