cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Quenot <...@anyware-tech.com>
Subject Re: Supporting "conditional GET" in Cocoon
Date Wed, 28 Dec 2005 10:15:34 GMT
* 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/

Mime
View raw message