Folks, HttpClient 4.0 ALPHA1 is almost ready for the prime time but there is a few things I would like to see tackled before the official release
(1) Port of all examples from HttpClient 3.x to new API (I'll take care of that in the coming says) (2) Decision about HTTP context hierarchies. Here's the background One of major differences compared to HttpClient 3.x API is the introduction of a concept of an HTTP execution context. HTTP requests always get executed within a specific execution context. The consumer of HttpClient API may choose to provide a different execution context to customize the process of the request execution. The context may have a different HttpState instance bound to it, a different set of protocol schemes or a different set of allowed authentication modules. All is nice and dandy and allows for a lot of flexibility. The trouble is currently the caller is expected to provide a fully initialized context with all requisite attributes bound to it. This can be a major pain in the rectum if all you want is to override the default HttpState instance, for instance. So, the idea is that HttpClient can somehow 'merge' the default settings with those provided in the custom context. There are several ways this could be done: * dumbly copy those attributes from the default context that are not explicitly defined in the custom one (will have performance costs) * 'link' contexts similarly to the way we link HttpParams in HttpCore (considered error-prone) * 'stack' the custom context on top of the default one using a decorator class of a kind (needs work) The latter approach goes hand in hand with the problem of building parameter hierarchies I and Roland have been wrestling with for quite some time. Do we want to invest more time into this issue in an attempt to get it right from the start or do we rather get HttpClient 4.0a1 out the door sooner and come up with the fix for 4.0a2 already having some preliminary feedback about the new API? What do you think? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
