Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
Date: 4 Sep 2003 02:09:40 -0000
Message-ID: <20030904020940.7582.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-httpclient-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 15435]  -
    New Preferences Architecture

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 02:09 -------
Hi Oleg,

I like it.  Overall the design is quite good.  I have number of ideas/questions which I will 
elaborate on below.

High level stuff:

 - How should we handle the storage of more complicated configuration options, like the date 
formats used in DateParser?  This is definitely something that I think should be able to 
configure, in the default case at least.  Another item that has been brought up is the ability to 
define a set of default headers to be applied to all methods.  Here a couple of ideas off the top 
of my head:

# 1 - delimit values
http.dateFormats=EEE, dd-MMM-yyyy HH:mm:ss z<SOME_DELIM>EEE dd-MMM-yyyy HH-mm-
ss z

# 2 - indirection
http.dateFormats=format1, format2
format1=EEE, dd-MMM-yyyy HH:mm:ss z
format2=EEE dd-MMM-yyyy HH-mm-ss z

The first choice is the easiest but has the delimiter choice problem.  The second choice is more 
exact but requires more work and is a little less obvious.  I think the solution here will depend 
somewhat on the answer to the next question.


 - Is there a need for both specific configuration params like getConnectionManagerTimeout() 
and generic ones like getParameter(String)?  I feel like we should have custom methods for all 
configuration values, or all generic ones with support for type specific params like 
getLongValue(String), but not both.  I am leaning more toward all specific configuration 
methods.  This configuration system is only meant to support HttpClient.  It should not need to 
be generic enough to be usable for other purposes.


Implementation details (perhaps too soon for this):

 - I think HttpParams.load() should use a PropertyResourceBundle to load/parse the 
configuration.  It avoids implementing the nasty details and provides support for splitting lines 
with "\", among other things.

 - I think we probably want a HttpMethodBase.setParams() or something of the sort.

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