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 02:09:40 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 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


Mime
View raw message