After a long period of inactivity I was able to spend some time on Cocoon in this weekend. I must confess that I'm really impressed with the work going on so far: Schecooon, XMLForm, Treeprocessor and so on are making Cocoon plans for world domination much closer to reality :-) Thanks to everyone for this wonderful software!
Now for the [VOTE] I'm calling. I'm recalling here the thread that I launched some time ago about cache friendly HTTP headers (see http://marc.theaimsgroup.com/?t=101074439900001&r=1&w=2 for details). I have a working[1] version sitting on my hard drive of a sitemap extension which allows to set custom "Expires" headers for every pipeline. The syntax (and functionality, and scope...) is compatible with Apache's mod_expires (see http://httpd.apache.org/docs/mod/mod_expires.html) from which the idea was stolen. With this modification you can configure a sitemap as follows: <pipeline expires="now plus 2 weeks"> <match pattern="images/**"> <read src="static/images/**" /> </match> <match pattern="files/*.html"> <generate src="static/files/{1}.xml" /> <transform src="style/my.xsl" /> <serialize/> </match> </pipeline> <pipeline expires="access plus 2 hours 15 minutes"> <match pattern="feed/*.html" /> <generate src="http://my-feed/{1}.rss"; /> <transform src="style/my.xsl" /> <serialize/> </match> </pipeline> <pipeline> <match pattern="dynamic/*.html" /> <generate src="this/changes/everytime/{1}.xml" /> <transform src="style/my.xsl" /> <serialize/> </match> </pipeline> Having in front of this setup a reverse proxy would massively help in building scalable sites, since many resources would be served by Cocoon only once in a while, with the proxy doing most of the job. My first tests are astonishing: with this setup scalability in most cases won't be an issue anymore. Not to mention usability in developing webapps: there would be no need anymore to mix and match static resources served by Apache for speed and scalability sake and synamic stuff served by your favourite app server: anything can be safely enclosed inside a webapp. Last but not least, this can be an enourmous bandwith saver. Note: at this point this has nothing to do with caching, infact Cocoon's internal cache is untouched. It might be worth considering, however, to make the expires settings available to the cache system so that it might be used to calculate/override resources lifetime a priori (the cache might have an implicit value for the resource validity). Enough blahblah, since this stuff has to do with the sitemap itself (there are no back incompatible changes but still it's a modification of the sitemap language), before committing I want to see if there is enough interest in it, so let's go for the votes: 1. Would you like this addition to be committed to HEAD? If so I promise to come up with documentations and a short HOWTO on how to connect a reverse proxy with Cocoon. 2. Would you like the "expires" settings to be available in the current ObjectModel so that the cache might become aware of it? Ciao, -- Gianugo Rabellino 1: well... almost: I need to understand some TreeProcessor quirks to see if I'm doing something wrong or if some exceptions I'm getting - while the setup is working - are normal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
