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 Thu, 04 Sep 2003 12:29:00 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 becke@u.washington.edu  2003-09-04 12:28 -------
I thought about this quite a bit more last night as I was going to sleep and I have changed
my 
mind, particularly in regard to specific vs. generic configuration.  My feeling now is that

HttpParams should be a source for generic configuration and that specific configuration should
be 
handled by the specific users of the values.  For example HttpParams would have methods like:

    String getParam(String key)
    long getLongParam(String key)

and default options like:

    String getParam(String key, String default)
    long getLongParam(String key, long default)

Then classes like HttpVersion or HttpMethodBase would have the specifics like:

    public static final String PARAM_PROTOCOL_VERSION = "http.protocol.version"

and

    public static void setHttpVersion(HttpVersion version, HttpParams params)

Again, these are just some ideas.  I like this separation of things better though.  This allows

HttpParams to be flexible enough to handle various kinds of configuration, and pushes the

specifics to the classes that care about them.

What do you think?

Mike

---------------------------------------------------------------------
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