> 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
- Original Message -
From: "Sung-Gu" <[EMAIL PROTECTED]>
To: "Kalnichevski, Oleg" <[EMAIL PROTECTED]>
Sent: Monday, June 23, 2003 11:47 AM
Subject: Re: URI & URIUtil as a separate Commons project?
> >
> > - Original Message -
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
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 classes clearly belongs to
