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 [EMAIL PROTECTED] 2003-09-04 14:22 ------- Folks, It's my first day at work after two weeks of holidays, so things are a bit hectic right now. I'll try to respond to every comment made but that may take a while and a few postings > # 2 - indirection > http.dateFormats=format1, format2 > format1=EEE, dd-MMM-yyyy HH:mm:ss z > format2=EEE dd-MMM-yyyy HH-mm-ss z That's the way Sun does it, and it may well be the way most users would expect it to work (me for one) > - Is there a need for both specific configuration params > like getConnectionManagerTimeout() and generic ones like getParameter (String)? Not really. I also agree that ideally two methods should not be mixed up. I sense that the majority of respondent favor the generic approach over specific, like I do. I just felt that having to parse some frequently values such as protocol version might be too much of a performance hit. I thought an exception could be made for the most frequently used parameters (maybe just protocol version). However, if we all agree that performance degradation will be offset by greater flexibility, I do not mind taking purely generic approach > - 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. Agreed. > - I think we probably want a HttpMethodBase.setParams() or something > of the sort. Can do. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
