On Tue, 4 Feb 2003, Incze Lajos wrote:
In message [EMAIL PROTECTED], Hen
ri Yandell writes:
I'm +1 to commons-uri.
What about commons-naming?
That's JNDI.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Sung-Gu wrote:
I don't think it's not mature... :(
They have couple of issues still, as I know.. just not revealed yet.
At least they have reached Alpha status! This is more than enough for a
real commons sub-project outside the sandbox.
for lazy consensus:
Let's replace Base64 in codec with the current HttpClient version.
Tim O'Brien
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 1:04 AM
To: Jakarta Commons Developers List
Subject: Re: more common
, 2003 1:04 AM
To: Jakarta Commons Developers List
Subject: Re: more common classes need a home
*commons.codec* sounds like a good place for this class. Perhaps you
could look at the various current implementations, and see if you can
provide a common Base64 class attractive to everyone in Jakarta
To: Jakarta Commons Developers List
Subject: Re: more common classes need a home
*commons.codec* sounds like a good place for this class. Perhaps you
could look at the various current implementations, and see if you can
provide a common Base64 class attractive to everyone in Jakarta
+1
Maybe chunked transfer encoding and URL encoding would fit into this
package as well somehow?
Odi
O'brien, Tim wrote:
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was
initially from the HttpClient project.
The codec Base64 class has an open bug which also should
Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 11:37 AM
To: Jakarta Commons Developers List
Subject: Re: [codec] RE: more common classes need a home
Maybe chunked transfer encoding and URL encoding would fit into this
package as well somehow
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 11:37 AM
To: Jakarta Commons Developers List
Subject: Re: [codec] RE: more common classes need a home
Maybe chunked transfer encoding and URL encoding would fit
On Mon, Feb 03, 2003 at 10:46:23AM -0600, O'brien, Tim wrote:
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was
initially from the HttpClient project.
The codec Base64 class has an open bug which also should point us in the
right direction:
My apologies, Scott, my apologies.
Tim O'Brien
-Original Message-
From: Scott Sanders [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 11:58 AM
To: Jakarta Commons Developers List
Subject: Re: [codec] RE: more common classes need a home
On Mon, Feb 03, 2003
I tried to read to the end of the thread so far before replying.
If the feeling is that the classes will see more use distributed
separately from HttpClient, I concur with Henri's assessment below.
In message [EMAIL PROTECTED], Hen
ri Yandell writes:
I'm +1 to commons-uri.
As Tim points out,
- Original Message -
From: Tomasz Pik [EMAIL PROTECTED]
Subject: Re: more common classes need a home
Jeffrey Dever wrote:
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
: Tomasz Pik [EMAIL PROTECTED]
Subject: Re: more common classes need a home
Jeffrey Dever wrote:
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java
Base64
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
put Base64 in commons-lang,
This goes into codec, which is still in Sandbox.
Infact there's already a Base64 there, but I'm not
sure how well it matches Slide's needs.
NOTICE
This e-mail and any attachments are confidential and may contain
*commons.codec* sounds like a good place for this class. Perhaps you
could look at the various current implementations, and see if you can
provide a common Base64 class attractive to everyone in Jakarta.
Currently these projects (at least) have one plus your new codec package:
tomcat
Jeffrey Dever wrote:
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java
Base64 into 'codec' but the rest?
commons-net is reserved... in the time of moving from
Jeffrey Dever wrote:
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java
First of all, I think these should come out of Slide as part of their
migration to
Jeffrey Dever wrote:
Also noticed that codec and xml-rpc also have their own Base64 classes.
You can also add Tomcat to the list.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Sounds like Base64 has found a home.
What are HttpsURL and HttpURL generally used for?
The various URI classes seem to need a home. They might be big enough
for their own package.
Where is URLUtil?
We should probably require the various classes as a dependency. The
only down side being
What are HttpsURL and HttpURL generally used for?
Nothing. They are never even imported in httpclient classes, they are
just ghosts in some comments and log strings. Thats part of the reason
why I want to move them away from here. Also I don't find them a
particularly useful abstraction
Jeffrey Dever wrote:
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java
Base64 into 'codec' but the rest?
commons-net is reserved... in the time of moving from
21 matches
Mail list logo
