* Ugo Cei: > Given the time of year, I'm afraid this message will fall on > deaf ears, but anyway ...
Some of us are still listening ;-) > I was recently startled to discover that there's apparently no > easy way to perform a proper "conditional GET" [1] using > Cocoon's sources. I wonder: didn't anybody ever try to implement > an RSS aggregator or other kind of HTTP client that frequently > requests seldom changing Web resources? And if someone did, > didn't he care about blindly fetching the whole resource every > time, even if not necessary? Shame on me, I wrote an RSS aggregator with Cocoon, but didn't care to fetch the resource twice every time because I just didn't notice. The pipeline I use for RSS is just generating the URL, and transforms result with the following stylesheet: http://svn.caraldi.com/trunk/www/webapps/portal/portal/xsl/rss.xsl > 8b. A "200 OK" status is returned, as the original resource has > perhaps been modified. isValid returns INVALID and Cocoon calls > the Source's getInputStream method anew. Everybody is NOT happy, > because the original resource has been fetched twice: once by > the SourceValidity and once by the Source itself. Sadly that is often the case. When I described « Calling SitemapSource.getInputStream() twice » I was exactly facing the same issue with CocoonSource, a class written for eXist to access a cocoon source. And this is a problem for all sources, not only HttpSource. See http://issues.apache.org/jira/browse/COCOON-1642 See http://cvs.sourceforge.net/viewcvs.py/exist/eXist-1.0/src/org/exist/source/CocoonSource.java?rev=1.8&view=log > So I thought really hard about the problem and came up > with a (hopefully) brilliant solution: Use a ThreadLocal. The > HttpSourceValidity will store in a ThreadLocal the response data > (actually an instance of HttpClient's GetMethod class) and the > HttpSource will use it later, in the same request and hence in > the same thread, to provide an InputStream for reading. Seems great. > One problem that might arise is due to the fact that with the > cocoon.xconf settings included in the patch, all "http" URIs > will be served by this Source, overriding the default handling > by Excalibur's URLSource. This could change the behavior of > existing applications, but it would strike me as strange having > to use some other pseudo-protocol (cached-http ?). If your patch is good enough, it may replace the existing HttpSource. Maybe doing some automated tests would help ensuring that there is no regression. Thanks a lot for your work, -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
