On Fri, 2010-08-13 at 11:28 -0400, Moore, Jonathan wrote: > Hi Oleg, > > I took a quick look, and see where you are going with this. My only > suggestion here is that I'm not sure that an HttpCache and a > ResourceFactory should both be constructors to the CachingHttpClient; > this feels to me like the CachingHttpClient is getting a little too deep > into the details of how the cache is going about managing its storage, > which ought not to be the concern of the CachingHttpClient. > > I think this can be addressed pretty simply, though, by altering the > HttpCache interface appropriately, and pushing the details of Resources > and ResourceFactories down into the classes that implement HttpCache. > > (So, for example, the constructor for the BasicHttpCache might > instantiate a HeapResourceFactory itself, and the ManagedHttpCache could > take a constructor where you can pass in a ResourceFactory). > > This simplifies the code in CachingHttpClient (probably just by moving > it elsewhere). I suspect this means that the BasicHttpCache can go back > to not being concerned with Resources or ResourceFactories at all (which > I would suggest is simpler and clearer). > > This then gives you flexibility to add cache implementations along > several ways: > 1. implement HttpCache outright (e.g. the memcached and ehcache packages > we're working on contributing) > 2. subclass or write analogues to the ManagedHttpCache and inject > existing ResourceFactories > 3. re-use the ManagedHttpCache and write a new ResourceFactory > > I think this maximizes flexibility while not adding complexity where it > isn't needed. > > I can take a stab at the rewrite I'm suggesting here if you don't have > time, although probably not until next week. > > Jon >
Hi Jon I am not sure it is feasible to completely decouple CachingHttpClient from the resource management details (ResourceFactory) unless you are willing to revert back to the state when CachingHttpClient always created an intermediate in-memory copy of the response content. Anyways, please do feel free to take a stab at it. cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
