hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 15435] - New Preferences Architecture
Date Fri, 19 Sep 2003 11:22:44 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435

New Preferences Architecture





------- Additional Comments From olegk@apache.org  2003-09-19 11:22 -------
Hi Roland. Welcome back.

> 1. Taking HttpClient as an example, I'm missing a constructor
>    HttpClient(HttpClientParams)
>    I really want a way to instantiate classes without triggering
>    the properties loading mechanism at all. Second best would be a
>    setParams(HttpClientParams), so I can simply copy the params
>    of another client. Ok, the copying idea makes more sense using
>    HttpMethodParams and HttpMethodBase as an example :-)

Addition of HttpClient#HttpClient(HttpClientParams) sounds reasonable. We might 
need to make DefaultHttpParams cloneable, which would be a good thing to do 
anyways

> HttpMethodParams and HttpClientParams are rather independent classes.
> Shouldn't they both be derived from DefaultHttpParams directly?

Any of parameters relevant on the HttpMethod level should also be settable on 
HttpClient level when applicable of a number of methods, IMO. Off course, there 
is no real need for 'extends' relationship between HttpClientParams and 
HttpMethodParams other than for reusing a few methods

Oleg

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


Mime
View raw message