What if we instead made separate facades for the memcached and ehcache packages?
So the constructors on DefaultCachingHttpClientFacade are: public DefaultCachingHttpClientFacade(); public DefaultCachingHttpClientFacade(CacheConfig config); public DefaultCachingHttpClientFacade(HttpClient client); public DefaultCachingHttpClientFacade(HttpClient client, CacheConfig config); and then we had EhcacheCachingHttpClientFacade with: public EhcacheCachingHttpClientFacade(Ehcache storage); public EhcacheCachingHttpClientFacade(Ehcache storage, CacheConfig config); public EhcacheCachingHttpClientFacade(Ehcache storage, HttpClient client); public EhcacheCachingHttpClientFacade(Ehcache storage, HttpClient client, CacheConfig config); (and then similar for memcached). Jon ........ Jon Moore Comcast Interactive Media -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Thu 9/30/2010 5:19 AM To: HttpComponents Project Subject: RE: roadmap for caching module 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 avoid. Oleg --------------------------------------------------------------------- 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]
