On Mon, 2007-05-21 at 18:02 +0200, Roland Weber wrote: > Hi Oleg, > > >> - HttpParams.setDefaults: get rid of (subject to review) > > > > Hhm. That would quite a major change. If we do away with ability to > > chain HTTP parameter objects into hierarchies > > I didn't plan to get rid of the hierarchies altogether. > I just want to make them an internal structure that can > not be messed up by clients calling .setDefaults() or > passing their own hierarchies into the API. > BasicHttpParams would become non-hierarchical, while > StackedHttpParams or some such class keeps a list of > two or three HttpParams to search for a value. I need > some time to scan the code for places where hierarchies > are used and to assess the impact of the change. >
Sounds reasonable. Actually we may also need stackable HttpContexts too. Currently the way to customize the process of HTTP request execution is to pass a custom instance of HttpContext to HttpClient#execute method. The trouble is, though, the default protocol interceptors expect quite a number of objects (attributes) to be bound to the context. What if the user wants to override the default HttpState instance only without having to mess around with all other attributes? There is a few options to achieve the desired effect, one of which would be to 'stack' contexts in some way thus allowing the custom context to draw upon the values set in the default context, if they are not set locally in the custom context. Just something to think about. Oleg > cheers, > Roland > > > --------------------------------------------------------------------- > 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]
