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();
...
following the filter idea from w3c's Jigsaw (not JTidy btw.), I would like to give my ideal version:
Filter cacheFilter = new CacheFilter();
httpClient.addFilter(cacheFilter, Filter.INOUT);
HttpMethod get = = new GetMethod("http://www.google.com";);
httpClient.executeMethod(get, ..);the difference is that there is NO specific code after the configuration of the client.
The architectural problem I see is that a mechanism like this has to be built in at the core level. Currently there is simply no way to transparently intercept a request (and response) just before it is being sent over the wire (or after it has been received), and to manipulate it or substitute it with the contents of a cache.
I think filters are a proven and generic concept from many other APIs (as Laura mentions). In fact, in Jigsaw even other things, like authentication, cookies, ICP (whatever that is) are done through filters.
I for my part would much prefer building pluggability into the core, and adding plugins externally, than having duplicate code.
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
