> Hmm... looks like... most're intersted in some uri encoding methods. (at
> least in the mailing list)
> However, I will say that URI is generally a parser for some purposes with
> having some coder feature.
>
> As I look into Commons-Codec, well... bula...bula...
> And I think it's not a right c
Adrian Sutton wrote:
Sounds quite reasonable. The other thing to consider is exactly how
much the URI classes are likely to change anyway. They pretty much do
what's required now and I find it hard to imagine there'd be too many
changes that need to be made.
Code can always be nicer and more f
On Tuesday, June 17, 2003, at 10:49 PM, Ortwin Glück wrote:
Kalnichevski, Oleg wrote:
1) URL encoding logic that constitutes almost a half of the reusable
code in URI related classes clearly belongs to Commons-Codec package.
URL encoding & decoding functions should be merged with Commons-Codec
ra
Kalnichevski, Oleg wrote:
1) URL encoding logic that constitutes almost a half of the reusable
code in URI related classes clearly belongs to Commons-Codec package.
URL encoding & decoding functions should be merged with Commons-Codec
rather than spun off. HttpClient will introduce Commons-Codec as
Kalnichevski, Oleg wrote:
Sung-Gu and all,
I must confess I have had a change of heart on this issue. I am no more convinced that URI & URIUtil classes should be spun off into a Commons project of its own.
1) URL encoding logic that constitutes almost a half of the reusable code in URI related cl
