hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: [HttpCore] HTTP parameters was Re: [HttpConn] test coverage
Date Mon, 28 May 2007 17:56:48 GMT
Hi Oleg,

> step 7) Always warp an instance of HttpParams with a wrapper class whose
> sole purpose is to implement HttpLinkedParams and maintain a reference
> to the upper level defaults . Even if the wrapped class implements
> HttpLinkedParams, its functionality gets effectively disabled.
> BasicHttpParams no longer needs to implements HttpLinkedParams. 

What I don't like about that is the "Always". The parameter stacks
I would like to introduce in the future should _not_ be extended
with linked defaults. I don't like the idea of dynamically linking
defaults. And if defaults are linked in advance, there is no point
in wrapping another layer of defaults.

+1 to moving the linking from BasicHttpParams to an extra class.

> This buys us two things. (1) we no longer need to create copies of
> params in #setParams() methods. We can simply wrap them.

We could wrap them outside of #setParams() if defaults are desired,
and require the caller to pass the exact object that is meant to be
used for params.

> (2) More
> importantly we can make BasicHttpParam non-synchronized per default.

Is it synchronized only because of the defaults? That could have
been addressed with a little care in getParameter(...), which is
the only method that makes two accesses to the defaults. A single
access is atomic.

+1 to making BasicHttpParams non-synchronized.

> What do you think?

I think we once more agree to disagree ;-(
I would like to have full control over the whole stack of
parameters outside of the parameterized classes. It seems
that you want to make the parameterized classes as safe
as possible for callers of #setParams().

Please go ahead with the changes mentioned above. We can
continue the discussion about the remaining details next
week-end. I'll be on a business trip starting tomorrow.


To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message