I would actually think that a nice generic caching library would be very beneficial, but it should definitely be outside of HttpClient as HttpClient is very regularly used without any desire for caching at all.
Agreed on both counts. I have a caching library that sits on top of HttpClient right now, and if I ever find the time I'm going to try to build a version of it that can be made open source. But I don't think it should go inside HttpClient; rather it should be a separate library that uses HttpClient.
There shouldn't be any obstacles in your way to implement caching.
It depends on what you want the cache's API to look like. I've been meaning to post about this lately, so here goes....
Ideally, I'd want the API for executing an HTTP method via the cache to look almost identical to the API for executing it directly with HttpClient. Something like:
HttpCache myCache = new HttpCache( new MultithreadedHttpConnectionManager());
HttpMethod get = new GetMethod("http://www.google.com";);
int statusCode = myCache.executeMethod(get, ...);
String type = get.getResponseHeader("Content-Type");
InputStream is = get.getResponseInputStream();
...
Unfortunately, you can't really do this with the current HttpClient architecture. The biggest "gotcha" is that the methods that set response-related fields on an HttpMethod are all private or protected -- things like setResponseStream, getResponseHeaderGroup, statusLine, etc. To make a cache API that looks like the current HttpClient API, I think it would be necessary to duplicate the existing method classes with versions that either construct their results from the cache or delegate to one of the HttpClient method classes depending on cacheability and so on.
Someone (Oleg, I think) has suggested splitting HttpMethod into two interfaces for 2.1 or 3.0: HttpRequest and HttpResponse. I really like that idea. Aside from being architecturally cleaner, that would make it much easier to create a clean cache API; the cache could just provide its own HttpResponse implementation. Another suggestion is to abstract out some of HttpClient's non-implementation-specific functionalityinto an interface that could be implemented by other HTTP providers like a cache.
I also like the idea of filters that Christian mentioned. Adding some hooks like that into HttpClient would probably make it more generally useful, though I don't know what the cost in complexity would be. I'll have to go look at the specifics of what JTidy does. I think Axis also has a similar notion of filter chains, and maybe Tomcat too (or servlet engines in general?).
-- Laura
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
