Oleg Kalnichevski wrote:
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)
Doesn't work with null values. The merger can not decide if I wanted to null the
value or if I don't want to override it.
* '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.
What about letting the client build a context with the default settings, that
the user can obtain and modify to his liking? This only works if we CAN build a
context from scratch.
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?
I don't think this is a critical feature for the first Alpha. It can always be
addressed in the next release or so. Getting feedback is the most important
thing at the moment.
What do you think?
Oleg
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
