Ugo Cei wrote:
Given the time of year, I'm afraid this message will fall on deaf ears, but anyway...
Ears aren't deaf, but on vacation :-)
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?
<snip/>
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.
I don't understand why you need a ThreadLocal. Isn't a class member good enough?
Also, this implementation, although useful, works only if the calling environment is "validity aware", i.e. keeps the validity of the previous usage of that same URL for comparison.
What would be more useful IMO, is for the HTTPSource to handle all that caching stuff transparently by directly using the cache and acting like a browser: if the response does have headers indicating cacheability, then pipe the getOutputStream() to the cache associated with the validity information, and later reuse this if still valid. This approach has the advantage of making HTTP cache handling totally transparent for the caller.
Ah, and a bug I just saw while re-reading the code: a SourceValidity *must* be serializable to be stored in the persistent store. The HttpSourceValidity references a HttpSource which itself is LogEnabled (not serializable) and has a HttpClient.
Sylvain -- Sylvain Wallez Anyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
