If we go with #3, we'll have to be careful about the conversion of protected methods to private ones, as this will likely break a bunch of unit tests. Generally speaking, though, the caching module follows the Façade design pattern, so most of the actual public API probably just wants to be whatever's needed to instantiate a CachingHttpClient instance.
The argument in favor of #2 would be that this is a good way to get more real world testing of the module, as it lowers the barrier to entry for potential users. This would be my preference, but I think #3 is pretty reasonable. That being said, I did want to add a little more information to the discussion. In the course of the week-long project that produced the first version of the caching API, we also wrote ehcache and memcached backends for the cache. Now, they haven't been brought up-to-date (yet) with the the recent changes (notably, the reimplementation of CacheEntry to make it immutable), but they probably could be with a little effort (the classes involved are just adapters, really). Let me see if I can get an estimate for when we could get those shipshape enough to contribute. Jon -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Monday, July 12, 2010 11:40 AM To: HttpComponents Project Subject: HttpClient 4.1 API freeze / Caching API Folks I would like to start moving towards the freeze of 4.1 API. All new features added in trunk since 4.0 seem reasonably okay. The only thing that still blocks the 4.1-beta1 release is the the relatively untested API of the recently added caching module. I personally find it difficult to decide for myself whether the design is flexible enough unless there are other implementations (for instance, a file system or a ehache based) of the same API. I see three different approaches we could pursue: (1) Take more time to stabilize HttpClientCache API at the price of delaying 4.1 GA. (2) Freeze the API of HttpClient and HttpMime and clearly state HttpClientCache is still experimental and its binary / API stability cannot be guaranteed, despite being a part of a GA release (3) Reduce the API to a bare minimum (make pretty much all but a few must-have classes package private, make protected methods of public classes private, etc) and gradually relax the restriction on class / method visibility as the module matures. What do you think? I am kind of leaning towards the last option. 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]
