hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sung-Gu" <jeri...@apache.org>
Subject Re: [VOTE] Re: 2.0 release - deprecate some methods?
Date Thu, 26 Jun 2003 12:05:37 GMT
My vote...  :D

FYI, (it's from URI javadoc messages,  I think they are related to your

     * The character set used to store files SHALL remain a local decision
     * MAY depend on the capability of local operating systems. Prior to the
     * exchange of URIs they SHOULD be converted into a ISO/IEC 10646 format
     * and UTF-8 encoded. This approach, while allowing international
     * of URIs, will still allow backward compatibility with older systems
     * because the code set positions for ASCII characters are identical to
     * one byte sequence in UTF-8.
     * Conversion from the local filesystem character set to UTF-8 will
     * normally involve a two step process. First convert the local
     * set to the UCS; then convert the UCS to UTF-8.
     * The first step in the process can be performed by maintaining a
     * table that includes the local character set code and the
     * UCS code.
     * The next step is to convert the UCS character code to the UTF-8
     * To work globally either requires support of a number of character
     * and to be able to convert between them, or the use of a single
     * character set.
     * For support of global compatibility it is STRONGLY RECOMMENDED that
     * clients and servers use UTF-8 encoding when exchanging URIs.

I've made sample cases and posted it before. (even if it's not a normal
junit testcase though.)
And I'm not willing to make testcase for that. I'm not interested in unicode
values... at all...

To help you guys, you could find the above sentences (it means that's from
RFC) and more specified how-to in a RFC describing FTP protocol, as I
guess... - I don't remember at all... :( ...


-----Original Message-----
From: Adrian Sutton [mailto:adrian@intencha.com]
Sent: Thu 6/26/2003 11:10
To: Commons HttpClient Project
Subject: [VOTE] Re: 2.0 release
Personally, I believe that this issue has gone on far too long and so I
would like to propose a vote:

I move the motion that the following methods from
org.apache.commons.httpclient.util.URIUtil be depreciated for the 2.0
release and removed in a future release:

toDocumentCharset(String, String)
toProtocolCharset(String, String)
toUsingCharset(String, String, String)

Please cast your votes:

+1 - The methods should be depreciated
0 - Active Abstain (no response being a passive abstain)
-1 - The methods should not be depreciated (veto)  Veto's must contain
an explanation of why the veto is appropriate.

Under Jakarta's voting guidelines
(http://jakarta.apache.org/site/decisions.html) product changes (such
as this) are subject to lazy consensus, however in this case I would
like to achieve consensus on the issue and as such the vote will be
considered passed if there are 3 binding +1 votes and no binding vetos
or the proposal will be turned down if there are any -1 votes.

I would encourage non-committers to submit non-binding votes as well,
particularly if you can see a use for the methods in question.

Here's my +1.


Adrian Sutton.

On Thursday, June 26, 2003, at 06:25  PM, Kalnichevski, Oleg wrote:

> Odi,
> Laura eventually conceded that these methods did not seem to make a
> lot of sense or were too specialized to be of any use for the majority
> of the HttpClient users.
> http://marc.theaimsgroup.com/?l=httpclient-commons-
> dev&m=104577672115772&w=2
> I do think that releasing HttpClient with stuff that makes no sense
> DOES harm.
> Again, after all, what is the bloody deal with writing a test case?
> Does it really have to take 5 months if these methods indeed make
> sense?
> Oleg

To unsubscribe, e-mail:
For additional commands, e-mail:


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message