Oleg Kalnichevski wrote:
Some of the stuff now in encodingUtil is dependent on HttpClient NameValuePair etc. and seems specifically for managing the encoding/building of query strings.
The ASCII stuff is just dependent in that it throws HttpclientError's
I suspect the later will be usefull to move out, while the former will be difficult without added complexity.
Mark, I agree. See what can be reused and makes sense to be reused. We'll play along.
I wonder what the best "design pattern" is for the ASCII conversion stuff. Is ASCII conversion to be considered "encoding" or string "translation"
See CharSetUtils in [lang]: http://jakarta.apache.org/commons/lang/api.1.0.1/org/apache/commons/lang/CharSetUtils.html#translate(java.lang.String,%20java.lang.String,%20java.lang.String)
It can certainly be seen as either depending on your particular angle. Design purism aside, for a very simple reason of keeping the number of external dependencies for HttpClient to the minimum, I would rather see these conversion routines a part of codec. I doubt HttpClient should be made dependent on Commons-Lang just because of ASCII conversion routines.
Oleg
I would agree when it comes to "simplicity" one should keep the dependencies to a "minimum". I expect to initially just use codec as a base for extracting these features from HttpClient. I've actually got the Changes to HttpClient worked out so that its using my extracted codebase. But, I should get the multipart codec accepted into codec before any changes occur in HttpClient.
I think that there is much architectural discussion to be had on the general Commons developer list concerning the appropriate location for character set and mimetype utilities. Converting something from one specific CharSet into another seems appropriate for both lang and codec. I think it should be the focus of some general discussion between these subgroups. Maybe there is another subproject that needs be created to maintain this stuff.
-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
