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.
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)
-Mark
Oleg Kalnichevski wrote:
Mark, Ironically, I just responded to your message on the commons-dev mailing list. I do think that EncodingUtil would fit quite well in codec
Cheers, Oleg
On Tue, 2004-01-13 at 20:19, Mark R. Diggory wrote:
Hey Guys, I didn't realize you were already doing this,
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25431
I should pay more attention to the bugzilla. I posted a message eariler today approaching the issues of HttpConstants encoding methods and there usefullness outside of HttpClient on the Commons developer list.
Do you guys think that the Ascii stuff in EncodingUtil could eventually move out into something like lang or codec?
Cheers, Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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]
