hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject RE: roadmap for caching module
Date Thu, 30 Sep 2010 09:19:54 GMT
On Wed, 2010-09-29 at 10:27 -0400, Moore, Jonathan wrote: 
> Hi Oleg,
> We actually have a dev team currently working on the cache-based 304s, and they will
be tackling the 'variant miss', only-if-cached, and heuristic caching in short order. I think
it is possible we might see those done within the next two weeks or so.
> At that point, I would feel pretty comfortable going for option (1) of releasing to GA
with caveats, as you mention. We'll benefit more from community input and usage than we will
from implementing the nice-to-haves of request collapsing, RFC5861, or byterange handling,
and I would be comfortable having those wait until 4.2.
> We could also take the approach of drastically limiting the public API to the point of
just allowing people to instantiate the existing client. I've been thinking about separating
the current CachingHttpClient class out into a faƧade class and an implementation class.
So CachingHttpClientImpl would be package-private and would have all the guts but just a single
constructor that takes all dependencies; all of the current instantiation work that goes on
in some of the constructors can then happen in the CachingHttpClientFacade (class names for
illustration purposes only...).
> Then we have the CachingHttpClientFacade just have the following constructors (plus variants
for each that also take a CacheConfig and/or the backing HttpClient):
> public CachingHttpClientFacade(); // default in-memory implementation
> public CachingHttpClientFacade(Ehcache storage);
> public CachingHttpClientFacade(MemcachedClientIF storage);
> So the only things a client can instantiate are a CachingHttpClientFacade and a CacheConfig.
This has the temporary drawback that folks won't be able to extend the implementation without
patching, but it vastly reduces the API surface and hence our risk of breaking binary compatibility
as we add the other features. Maybe it also encourages people to submit patches. :)
> I recently read an article somewhere where a project only exposes public API when someone
asks for it; we could take the same approach here and just really lock it down while we're
under development, rather than trying to anticipate how people will want to extend it now.
> Jon

I like the idea of restricting the public API to an absolute minimum.
The only problem is that the proposed facade class will make dependency
on Ehcache and memcached mandatory, which is something I would like to


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message