You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jeffrey Dever <js...@sympatico.ca> on 2003/02/03 01:17:00 UTC
more common classes need a home
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 commons-httpclient which is still underway.
Second, I thnk that these classes are too general to be part of
HttpClient. They have use well beyond a http client, and so should be
available to other packages without requiring the commons-httpclient.jar.
Do people agree with me? If so, any idea where these could go? Perhaps
the root of org.apache.commons? or a new commons-net package? put
Base64 in commons-lang, and create a new commons-uri package?
If we do this, would it be better for HttpClient to roll the classes
into the commons-httpclient.jar, or require it as a dependancy?
Any comments would be helpful.
Jandalf.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: more common classes need a home
Posted by Ortwin Glück <or...@nose.ch>.
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.
Re: more common classes need a home
Posted by Sung-Gu <je...@apache.org>.
----- Original Message -----
From: "Jeffrey Dever" <js...@sympatico.ca>
Subject: Re: more common classes need a home
> The re-use structure is completely package based. So smaller packages
> are more re-usable. I think a commons.uri package with those 6 or 8
> files is a nice, small, focused, re-usable package.
I agree with you, as you wish. ;)
> These classes are quite mature and so do not need to be in the sandbox:
I don't think it's not mature... :(
They have couple of issues still, as I know.. just not revealed yet.
> they should be allowed to go right into commons proper. I'm willing to
> help out with the administrative aspect of setting up a commons-uri
> project including project proposal, releases, stuff like that.
I think your help will be very helpful in commons-sandbox right now... ^^;
Sung-Gu
>
> Sung-Gu wrote:
>
> > I think, as I see, 'Jakarta commons' indicates the square of
applications
> >for the small fuctions usefule to be used by other projects or
> >applications.
> > It means there aren't any way to refer to some or several reusable
> >classes in an easiness. BTW, jsd is asking to refer and use some
classes,
> >I guess. Any suggestions?
> >
> > Since the commons package has not been for only re-usable classes, (but
> >small apps)
> >I think it's better for me to start a new sandbox using URI and related
> >classes.
> >If it were going on, it would be an experimetal web client based on a new
> >archicture.
> >
> >Sung-Gu
> >
> >----- Original Message -----
> >From: "Tomasz Pik" <pi...@ais.pl>
> >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 into 'codec' but the rest?
> >>commons-net is reserved... in the time of moving from 'sandbox'.
> >>Maybe it's a good moment for change from commons-net to
> >>commons-protocols? Or maybe those classes should go into
> >>commons-lang (another subpackage, lang.net, another long
> >>discussion about the scope of lang :-)?
> >>
> >>--
> >>Regards
> >>Tomek Pik
> >>
> >>
> >>
> >>>Jandalf.
> >>>
> >>>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
Re: more common classes need a home
Posted by Jeffrey Dever <js...@sympatico.ca>.
The re-use structure is completely package based. So smaller packages
are more re-usable. I think a commons.uri package with those 6 or 8
files is a nice, small, focused, re-usable package.
These classes are quite mature and so do not need to be in the sandbox:
they should be allowed to go right into commons proper. I'm willing to
help out with the administrative aspect of setting up a commons-uri
project including project proposal, releases, stuff like that.
Any experimental web client work should be done in the sandbox seperately.
Sung-Gu wrote:
> I think, as I see, 'Jakarta commons' indicates the square of applications
>for the small fuctions usefule to be used by other projects or
>applications.
> It means there aren't any way to refer to some or several reusable
>classes in an easiness. BTW, jsd is asking to refer and use some classes,
>I guess. Any suggestions?
>
> Since the commons package has not been for only re-usable classes, (but
>small apps)
>I think it's better for me to start a new sandbox using URI and related
>classes.
>If it were going on, it would be an experimetal web client based on a new
>archicture.
>
>Sung-Gu
>
>----- Original Message -----
>From: "Tomasz Pik" <pi...@ais.pl>
>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 into 'codec' but the rest?
>>commons-net is reserved... in the time of moving from 'sandbox'.
>>Maybe it's a good moment for change from commons-net to
>>commons-protocols? Or maybe those classes should go into
>>commons-lang (another subpackage, lang.net, another long
>>discussion about the scope of lang :-)?
>>
>>--
>>Regards
>>Tomek Pik
>>
>>
>>
>>>Jandalf.
>>>
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
Re: more common classes need a home
Posted by Sung-Gu <je...@apache.org>.
I think, as I see, 'Jakarta commons' indicates the square of applications
for the small fuctions usefule to be used by other projects or
applications.
It means there aren't any way to refer to some or several reusable
classes in an easiness. BTW, jsd is asking to refer and use some classes,
I guess. Any suggestions?
Since the commons package has not been for only re-usable classes, (but
small apps)
I think it's better for me to start a new sandbox using URI and related
classes.
If it were going on, it would be an experimetal web client based on a new
archicture.
Sung-Gu
----- Original Message -----
From: "Tomasz Pik" <pi...@ais.pl>
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 into 'codec' but the rest?
> commons-net is reserved... in the time of moving from 'sandbox'.
> Maybe it's a good moment for change from commons-net to
> commons-protocols? Or maybe those classes should go into
> commons-lang (another subpackage, lang.net, another long
> discussion about the scope of lang :-)?
>
> --
> Regards
> Tomek Pik
>
> > Jandalf.
[net] name clash? (Was: more common classes need a home)
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 3 Feb 2003, Tomasz Pik wrote:
> 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 'sandbox'.
> Maybe it's a good moment for change from commons-net to
> commons-protocols? Or maybe those classes should go into
> commons-lang (another subpackage, lang.net, another long
> discussion about the scope of lang :-)?
Definitely outside commons-lang scope I think. I'd have said 'commons-net'
too, but there is already a project there. Any ideas from the [net]
people? :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[net] name clash? (Was: more common classes need a home)
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 3 Feb 2003, Tomasz Pik wrote:
> 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 'sandbox'.
> Maybe it's a good moment for change from commons-net to
> commons-protocols? Or maybe those classes should go into
> commons-lang (another subpackage, lang.net, another long
> discussion about the scope of lang :-)?
Definitely outside commons-lang scope I think. I'd have said 'commons-net'
too, but there is already a project there. Any ideas from the [net]
people? :)
Hen
Re: more common classes need a home
Posted by Tomasz Pik <pi...@ais.pl>.
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 'sandbox'.
Maybe it's a good moment for change from commons-net to
commons-protocols? Or maybe those classes should go into
commons-lang (another subpackage, lang.net, another long
discussion about the scope of lang :-)?
--
Regards
Tomek Pik
> Jandalf.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: more common classes need a home
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Jeffrey Dever wrote:
> Also noticed that codec and xml-rpc also have their own Base64 classes.
You can also add Tomcat to the list.
Re: more common classes need a home
Posted by Jeffrey Dever <js...@sympatico.ca>.
Also noticed that codec and xml-rpc also have their own Base64 classes.
The NameValuePair is also a candidate for a more general package
(perhaps lang?)
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 commons-httpclient which is still underway.
>
> Second, I thnk that these classes are too general to be part of
> HttpClient. They have use well beyond a http client, and so should be
> available to other packages without requiring the commons-httpclient.jar.
>
> Do people agree with me? If so, any idea where these could go?
> Perhaps the root of org.apache.commons? or a new commons-net
> package? put Base64 in commons-lang, and create a new commons-uri
> package?
>
> If we do this, would it be better for HttpClient to roll the classes
> into the commons-httpclient.jar, or require it as a dependancy?
>
> Any comments would be helpful.
>
> Jandalf.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
>
Re: more common classes need a home
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
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 commons-httpclient which is still underway.
>
> Second, I thnk that these classes are too general to be part of
> HttpClient. They have use well beyond a http client, and so should be
> available to other packages without requiring the commons-httpclient.jar.
>
> Do people agree with me? If so, any idea where these could go?
> Perhaps the root of org.apache.commons? or a new commons-net
> package? put Base64 in commons-lang, and create a new commons-uri
> package?
Base64 at least is in the Commons Codec package, which is currently in
the sandbox.
In Apache XML-RPC, we recently discovered interoperability problems with
Base64, and fixed them. We will be pushing these changes upstream to Codec.
We are leaning towards introducing a dependency instead of rolling them
into our JARs, as some of the contributors have found wierd classloader
problems if the same class is in the classpath more than once.
I would agree with you for the others, they are useful to more than just
this project.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: more common classes need a home
Posted by Tomasz Pik <pi...@ais.pl>.
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 'sandbox'.
Maybe it's a good moment for change from commons-net to
commons-protocols? Or maybe those classes should go into
commons-lang (another subpackage, lang.net, another long
discussion about the scope of lang :-)?
--
Regards
Tomek Pik
> Jandalf.
Re: more common classes need a home
Posted by Jeffrey Dever <js...@sympatico.ca>.
>
> 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 that justifies an inheritence hierachy.
>
> The various URI classes seem to need a home. They might be big enough
> for their own package.
org.apache.jakarta.commons.uri
Sounds like a good candidate to me. Sung-Gu appears to be the only one
who works on these (same story in the Slide project) so it would be good
to hear what he has to say.
>
> Where is URLUtil?
Dunno. Seems logical though.
>
> We should probably require the various classes as a dependency. The
> only down side being that a person has to download a lot more jars,
> etc. to get started working with HttpClient. It's kind of nice to
> have everything in one jar. Perhaps that could be a release option.
> We could package everything in one jar as a "fat" release and have
> just HttpClient code as another "skinny" option.
We still have this problem now, as commons-logging is required to build
or run httpclient. This is where I look to Commons to provide some
guidance on this as its a general project problem.
Jandalf.
Re: more common classes need a home
Posted by Michael Becke <be...@u.washington.edu>.
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 that a person has to download a lot more jars,
etc. to get started working with HttpClient. It's kind of nice to have
everything in one jar. Perhaps that could be a release option. We
could package everything in one jar as a "fat" release and have just
HttpClient code as another "skinny" option.
Mike
On Sunday, February 2, 2003, at 07:17 PM, 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 commons-httpclient which is still underway.
>
> Second, I thnk that these classes are too general to be part of
> HttpClient. They have use well beyond a http client, and so should be
> available to other packages without requiring the
> commons-httpclient.jar.
>
> Do people agree with me? If so, any idea where these could go?
> Perhaps the root of org.apache.commons? or a new commons-net package?
> put Base64 in commons-lang, and create a new commons-uri package?
>
> If we do this, would it be better for HttpClient to roll the classes
> into the commons-httpclient.jar, or require it as a dependancy?
>
> Any comments would be helpful.
>
> Jandalf.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>