You got me! ;)
Sung-Gu
- Original Message -
From: André-John Mas [EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED]
Sent: Friday, June 27, 2003 12:23 AM
Subject: Re: [VOTE] Re: 2.0 release - deprecate some methods?
This doesn't look correct, if you are really
+1
Adrian Sutton wrote:
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)
toDocumentCharset(String, String)
toProtocolCharset(String)
+1
-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Thu 6/26/2003 11:10
To: Commons HttpClient Project
Cc:
Subject:[VOTE] Re: 2.0 release
All,
Personally, I believe that this issue has gone on far too long and so I
would like to propose a
-1
My vote... :D
FYI, (it's from URI javadoc messages, I think they are related to your
topic.)
[snip]
* The character set used to store files SHALL remain a local decision
and
* MAY depend on the capability of local operating systems. Prior to the
* exchange of URIs they
Sung-Gu wrote:
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...
Sung-Gu,
I there are no test cases, how can we be sure these methods do what they
are
+1
On Thursday, June 26, 2003, at 05:10 AM, Adrian Sutton wrote:
All,
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
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
are supposed to do? I find it dangerous to have code that nobody
Ok, Sorry, then as you wish, I'll change my vote +1.
I hope you're happy...
understands (except of you) without any test cases.
Actually, I don't understand
Actually, I don't understand that you might notice and you might wonder
why there is encoding change menu in your web browser. and you can
test it yourself though.
Knock, knock. Hello, anybody home? Half a year ago, when this whole story started I
tried to explain you one simple thing: in
Adrian,
+1
OK, my vote is non-binding, but with no test cases, and no code in
HttpClient that uses the functions, we SHOULD deprecate them.
Even if we decide later, as Sung-Gu suggested, that we might need to
ressurrect them, we should still deprecate them! Deprecating them is a
flag for
- Original Message -
From: Adrian Sutton [EMAIL PROTECTED]
If you don't know why the code would be useful or what it was
implemented based upon, why is it that you still want it in HttpClient?
There is nothing that uses those methods anywhere in HttpClient and
the presence of an
- Original Message -
From: Eric Johnson [EMAIL PROTECTED]
Even if we decide later, as Sung-Gu suggested, that we might need to
ressurrect them, we should still deprecate them! Deprecating them is a
Done.
Sung-Gu
+1
As these methods are not used by HttpClient and do not appear useful for
httpclient for httpclient users combined with the reality that they do
not appear correct and the pending desire to start a Commons-URI project
indicates that they should not be in the public interface of HttpClient.
Adrian Sutton wrote:
The flaw in the toUsingCharset method is two-fold:
Firstly, Strings in Java are *always* stored internally as UTF-8
I agree with the rest of your analysis of this, but I thought I should
point out that Java Strings and chars are stored in UTF-16 rather than
UTF-8. A char
Subject: Re: [VOTE] Re: 2.0 release - deprecate some methods?
- Original Message -
From: Adrian Sutton [EMAIL PROTECTED]
If you don't know why the code would be useful or what it was
implemented based upon, why is it that you still want it in HttpClient?
There is nothing
Sung-Gu wrote:
But, not a duty... it's voluteering... no pay...
even the code constribution here...
I pay you $5 for test cases from my Paypal account. Promise.
:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
This doesn't look correct, if you are really wanting to convert
from one charset to another then you would have to do something
such as:
String myString = new String(bytes,bytesCharset);
byte[] bytes2 = myString.getBytes(destCharset);
Until you have the bytes, you don't have the final
] Re: 2.0 release - deprecate some methods?
This doesn't look correct, if you are really wanting to convert
from one charset to another then you would have to do something
such as:
String myString = new String(bytes,bytesCharset);
byte[] bytes2 = myString.getBytes(destCharset);
Until you
On Thu, 2003-06-26 at 23:40, [EMAIL PROTECTED] wrote:
I just got through Internationalizing a website... input and output. I
ran into the exact same issues, and as Andre states, you pretty much need
to check everywhere for byte[] -String and String-byte[].
Matt, we actually do. We do have
This doesn't look correct, if you are really wanting to convert
from one charset to another then you would have to do something
such as:
String myString = new String(bytes,bytesCharset);
byte[] bytes2 = myString.getBytes(destCharset);
Until you have the bytes, you don't have the final
19 matches
Mail list logo
