> 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 choice. (I guess, probably they wouldn't
think
> either)

Sung-Gu,

What do you mean by "As I look into Commons-Codec, well... bula...bula..."?

Undoubtedly, URI specification doesn't belong to Commons-Codec. No one has ever 
suggested otherwise. The idea is to factor out only URL encoding/decoding logic that 
clearly does.


> > 2) URI specification by itself is just one class. It hardly makes any
> sense in my opinion to make a package out of it, even though URI class is
> clearly useful beyond HttpClient.
>
> If you want make an jar, you'd better setup the build.xml when you tar
it...

This is not just about creating a separate jar file with URI spec implementation. The 
initial idea was to create Commons-URI sub-project out of existing URI spec 
implementation in HttpClient. However, as many pointed out, the overhead of 
maintaining a full fledged Jakarta Commons sub-project around what is essentially one 
class would be simply too much. This said, if you can write a proposal for Commons-URI 
sub-project and make a convincing case to the rest of the Jakarta Commons community, 
we will whole-heartedly support you.

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to