Re: EncodingUtils
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]
Re: EncodingUtils
> 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EncodingUtils
Another feature of interest is the ContentType class in contributions, I suspect this should be more dependent on some general mimetype resolution functionality possibly via JAF or some comparable standard mimetype mapping library. This is something I'm researching as well for codec or lang (or possibly a new "mime" library). -Mark Mark R. Diggory wrote: Lol, I was trying to catch up with you... 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]
Re: EncodingUtils
Lol, I was trying to catch up with you... 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]
Re: EncodingUtils
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]
