You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Jeffrey Dever <js...@sympatico.ca> on 2003/02/07 18:41:08 UTC
Propose a new commons-uri package
This is just a draft regarding factoring out the URI based code in
HttpClient into its own dedicated package. Please comment.
(0) rationale
The concept of a URI is prevelent in networking. A specific form of
URI, a URL is used ubiquitously across the internet. Currently
HttpClient houses the URI and URL based classes, but these have much
broader use. This common functionality should be housed in its own
dedicated, small, reusable package. Any projects that require URI, URL
or URN functionality can do so by importing a small, focused package,
commons-uri.jar.
(1) scope of the package
The package shall provide a complete java implementation of RFC2396.
This includes the URI as well as URL and URN classes and utilities.
The implementation will be fully character set aware.
(1.5) interaction with other packages
Have no dependancies beyond the standard java packages.
*
(2) identify the initial source for the packages
Various classes in common from from Commons HttpClient Jakarta Slide.
(2.1) identify the base name for the package
org.apache.commons.uri
(2.2) identify the coding conventions for this package
The code uses the conventions from the Jakarta Commons.
(2.1) Identify the initial file structure
jakarta-commons/org/apache/commons/uri
uri/
URI.java
URIUtil.java
URIException.java
url/
HttpsURL.java
HttpURL.java
urn/
(3) identify any Jakarta-Commons resources to be created
(3.1) mailing list
commons-dev@jakarta.apache.org
(3.2) CVS repositories
jakarta-commons/uri
(3.3) Bugzilla
The package should be listed as the uri component under the
Jakarta-Commons Bugzilla entry.
(4) identify the initial set of committers to be listed in the Status File.
Jeff Dever (jsdever)
Sung-Gu Park (jericho)
others?
Re: Propose a new commons-uri package
Posted by Michael Becke <be...@u.washington.edu>.
Sounds like a good plan. I am happy to help if needed.
One quick question regarding the HttpURL and HttpsURL classes. I
mentioned this earlier when you were discussing the commons-uri package.
Are these classes needed and would we want to bring them in to a new
package?
Mike
Jeffrey Dever wrote:
>
>
> This is just a draft regarding factoring out the URI based code in
> HttpClient into its own dedicated package. Please comment.
>
> (0) rationale
>
> The concept of a URI is prevelent in networking. A specific form of
> URI, a URL is used ubiquitously across the internet. Currently
> HttpClient houses the URI and URL based classes, but these have much
> broader use. This common functionality should be housed in its own
> dedicated, small, reusable package. Any projects that require URI, URL
> or URN functionality can do so by importing a small, focused package,
> commons-uri.jar.
>
> (1) scope of the package
>
> The package shall provide a complete java implementation of RFC2396.
> This includes the URI as well as URL and URN classes and utilities. The
> implementation will be fully character set aware.
>
> (1.5) interaction with other packages
>
> Have no dependancies beyond the standard java packages.
>
> *
>
> (2) identify the initial source for the packages
>
> Various classes in common from from Commons HttpClient Jakarta Slide.
>
> (2.1) identify the base name for the package
>
> org.apache.commons.uri
>
> (2.2) identify the coding conventions for this package
>
> The code uses the conventions from the Jakarta Commons.
>
> (2.1) Identify the initial file structure
>
> jakarta-commons/org/apache/commons/uri
>
> uri/
> URI.java
> URIUtil.java
> URIException.java
> url/
> HttpsURL.java
> HttpURL.java
> urn/
> (3) identify any Jakarta-Commons resources to be created
>
> (3.1) mailing list
>
> commons-dev@jakarta.apache.org
>
> (3.2) CVS repositories
>
> jakarta-commons/uri
>
> (3.3) Bugzilla
>
> The package should be listed as the uri component under the
> Jakarta-Commons Bugzilla entry.
>
> (4) identify the initial set of committers to be listed in the Status File.
>
> Jeff Dever (jsdever)
> Sung-Gu Park (jericho)
> others?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
Re: Propose a new commons-uri package
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
The decision to require JDK 1.4 for HttpClient is not trivial. In
XML-RPC, we are still debating whether to abandon 1.1 and require 1.2+.
We use HttpClient in our library.
Furthermore, the idea is to share the URI functionality among Apache
projects. Other projects that use URI functionality include Xerces,
maybe Xalan, Slide, James?, Cactus, and Tomcat. (That's just off the
top of my head).
Brett Knights wrote:
>Would the intention of this be to reproduce the functionality of
>java.net.URI
>as found in J2SE 1.4?
>
>java.net.URI seems quite complete.
>
>If so how many people can't make the switch to 1.4? I am not using
>1.4.x in producion yet but I have been doing all my development with
>1.4.1 so at this point it is just a matter of mustering the energy for
>installing jdk's and running tests etc.
>
>
>
>----- Original Message -----
>From: "Jeffrey Dever" <js...@sympatico.ca>
>To: "Commons HttpClient Project"
><co...@jakarta.apache.org>
>Sent: Friday, February 07, 2003 9:41 AM
>Subject: Propose a new commons-uri package
>
>
>
>
>>This is just a draft regarding factoring out the URI based code in
>>HttpClient into its own dedicated package. Please comment.
>>
>>(0) rationale
>>
>>The concept of a URI is prevelent in networking. A specific form of
>>URI, a URL is used ubiquitously across the internet. Currently
>>HttpClient houses the URI and URL based classes, but these have much
>>broader use. This common functionality should be housed in its own
>>dedicated, small, reusable package. Any projects that require URI,
>>
>>
>URL
>
>
>>or URN functionality can do so by importing a small, focused
>>
>>
>package,
>
>
>>commons-uri.jar.
>>
>>(1) scope of the package
>>
>>The package shall provide a complete java implementation of RFC2396.
>> This includes the URI as well as URL and URN classes and utilities.
>> The implementation will be fully character set aware.
>>
>>(1.5) interaction with other packages
>>
>>Have no dependancies beyond the standard java packages.
>>
>> *
>>
>>(2) identify the initial source for the packages
>>
>>Various classes in common from from Commons HttpClient Jakarta
>>
>>
>Slide.
>
>
>>(2.1) identify the base name for the package
>>
>>org.apache.commons.uri
>>
>>(2.2) identify the coding conventions for this package
>>
>>The code uses the conventions from the Jakarta Commons.
>>
>>(2.1) Identify the initial file structure
>>
>>jakarta-commons/org/apache/commons/uri
>>
>>uri/
>> URI.java
>> URIUtil.java
>> URIException.java
>> url/
>> HttpsURL.java
>> HttpURL.java
>> urn/
>>
>>(3) identify any Jakarta-Commons resources to be created
>>
>>(3.1) mailing list
>>
>>commons-dev@jakarta.apache.org
>>
>>(3.2) CVS repositories
>>
>>jakarta-commons/uri
>>
>>(3.3) Bugzilla
>>
>>The package should be listed as the uri component under the
>>Jakarta-Commons Bugzilla entry.
>>
>>(4) identify the initial set of committers to be listed in the
>>
>>
>Status File.
>
>
>>Jeff Dever (jsdever)
>>Sung-Gu Park (jericho)
>>others?
>>
>>
Re: supported jre version [was Re: Propose a new commons-uri package]
Posted by Jeffrey Dever <js...@sympatico.ca>.
Good point. In general, the examples should also baseline jdk1.2. If
there is a specific reason for using a 1.3 or 1.4 feature in some case,
than that would be OK as long as its clearly stated.
We would have to deal with that on a compilation level somehow as well.
Jandalf.
Oleg Kalnichevski wrote:
>Jandalf
>
>I have no problem compiling HttpClient with JDK 1.2.2 + JCE 1.2.2 + JSSE
>1.0.3.01, as well as test cases. However, several examples require newer
>JDK: PostXML, ClientApp, MultiPartUploadApp. Do you think examples
>should also be JDK 1.2.2 compatible? I tend to believe they should
>
>Cheers
>
>Oleg (Olegolas)
>
>
>
>On Fri, 2003-02-07 at 23:16, Jeffrey Dever wrote:
>
>
>>Agreed. If we were building an application, then we could arbitrairly
>>decide to use whichever jre version that was most suitable. But we are
>>not building an application, we are building a framework. As a result
>>we must support the lowest reasonable version. This has always been
>>jre1.2.x
>>
>>Which reminds me, next time I better actually compile the release build
>>with 1.2 ... I'll update the release process.
>>
>>Jandalf.
>>
>>
>>Oleg Kalnichevski wrote:
>>
>>
>>
>>>I am also of opinion that for the time being Java 1.2.2 should be
>>>considered the lowest common denominator. Doing otherwise would
>>>completely preclude several major platforms from being able to run
>>>HttpClient. Please correct me if I err, but as far as I know IBM only
>>>supports Java 1.3.1 on its operating systems (such as AIX), with IBM
>>>Java 1.4.1 still being in beta. Mac OS X does not support Java 1.4.1
>>>either, at least not yet. The use of Java 1.4.1 specific features should
>>>be ruled out for a few years to come (IMHO)
>>>
>>>Oleg
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
Re: supported jre version [was Re: Propose a new commons-uri
package]
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
Jandalf
I have no problem compiling HttpClient with JDK 1.2.2 + JCE 1.2.2 + JSSE
1.0.3.01, as well as test cases. However, several examples require newer
JDK: PostXML, ClientApp, MultiPartUploadApp. Do you think examples
should also be JDK 1.2.2 compatible? I tend to believe they should
Cheers
Oleg (Olegolas)
On Fri, 2003-02-07 at 23:16, Jeffrey Dever wrote:
> Agreed. If we were building an application, then we could arbitrairly
> decide to use whichever jre version that was most suitable. But we are
> not building an application, we are building a framework. As a result
> we must support the lowest reasonable version. This has always been
> jre1.2.x
>
> Which reminds me, next time I better actually compile the release build
> with 1.2 ... I'll update the release process.
>
> Jandalf.
>
>
> Oleg Kalnichevski wrote:
>
> >I am also of opinion that for the time being Java 1.2.2 should be
> >considered the lowest common denominator. Doing otherwise would
> >completely preclude several major platforms from being able to run
> >HttpClient. Please correct me if I err, but as far as I know IBM only
> >supports Java 1.3.1 on its operating systems (such as AIX), with IBM
> >Java 1.4.1 still being in beta. Mac OS X does not support Java 1.4.1
> >either, at least not yet. The use of Java 1.4.1 specific features should
> >be ruled out for a few years to come (IMHO)
> >
> >Oleg
> >
> >
> >---------------------------------------------------------------------
> >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
>
supported jre version [was Re: Propose a new commons-uri package]
Posted by Jeffrey Dever <js...@sympatico.ca>.
Agreed. If we were building an application, then we could arbitrairly
decide to use whichever jre version that was most suitable. But we are
not building an application, we are building a framework. As a result
we must support the lowest reasonable version. This has always been
jre1.2.x
Which reminds me, next time I better actually compile the release build
with 1.2 ... I'll update the release process.
Jandalf.
Oleg Kalnichevski wrote:
>I am also of opinion that for the time being Java 1.2.2 should be
>considered the lowest common denominator. Doing otherwise would
>completely preclude several major platforms from being able to run
>HttpClient. Please correct me if I err, but as far as I know IBM only
>supports Java 1.3.1 on its operating systems (such as AIX), with IBM
>Java 1.4.1 still being in beta. Mac OS X does not support Java 1.4.1
>either, at least not yet. The use of Java 1.4.1 specific features should
>be ruled out for a few years to come (IMHO)
>
>Oleg
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
Re: Propose a new commons-uri package
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
I am also of opinion that for the time being Java 1.2.2 should be
considered the lowest common denominator. Doing otherwise would
completely preclude several major platforms from being able to run
HttpClient. Please correct me if I err, but as far as I know IBM only
supports Java 1.3.1 on its operating systems (such as AIX), with IBM
Java 1.4.1 still being in beta. Mac OS X does not support Java 1.4.1
either, at least not yet. The use of Java 1.4.1 specific features should
be ruled out for a few years to come (IMHO)
Oleg
Re: Propose a new commons-uri package
Posted by Mike Moran <mi...@mac.com>.
On Friday, February 7, 2003, at 07:13 PM, Brett Knights wrote:
> Would the intention of this be to reproduce the functionality of
> java.net.URI
> as found in J2SE 1.4?
>
> java.net.URI seems quite complete.
>
> If so how many people can't make the switch to 1.4? I am not using
> 1.4.x in producion yet but I have been doing all my development with
> 1.4.1 so at this point it is just a matter of mustering the energy for
> installing jdk's and running tests etc.
If HttpClient made jdk 1.4 a requirement then I think it would be the
end of any possible usage for me. In some contexts, where it would be
used on a server mostly, it could be done, but on the desktop, it's far
more complicated.
Is it really worth incurring the 1.4 upgrade hit for something as small
as the URI class? Regardless of this point, given the turnaround of
bug-fixing in the jdk generations, it would be foolhardy to assume that
the URI class is feature complete and totally bug-free (especially
given some of the subtleties). In jdk-land, if you have found a bug,
you could have submitted it years ago and *still* be waiting for a fix.
I think I would rather have control over something as fundamental as
URI handling.
I could perhaps see the point of a move to jdk1.4 if it was because of
some super-duper java.nio non-blocking wonderfulness, but for one class?
--
Mike
Re: Propose a new commons-uri package
Posted by Brett Knights <br...@knightsofthenet.com>.
Would the intention of this be to reproduce the functionality of
java.net.URI
as found in J2SE 1.4?
java.net.URI seems quite complete.
If so how many people can't make the switch to 1.4? I am not using
1.4.x in producion yet but I have been doing all my development with
1.4.1 so at this point it is just a matter of mustering the energy for
installing jdk's and running tests etc.
----- Original Message -----
From: "Jeffrey Dever" <js...@sympatico.ca>
To: "Commons HttpClient Project"
<co...@jakarta.apache.org>
Sent: Friday, February 07, 2003 9:41 AM
Subject: Propose a new commons-uri package
>
>
> This is just a draft regarding factoring out the URI based code in
> HttpClient into its own dedicated package. Please comment.
>
> (0) rationale
>
> The concept of a URI is prevelent in networking. A specific form of
> URI, a URL is used ubiquitously across the internet. Currently
> HttpClient houses the URI and URL based classes, but these have much
> broader use. This common functionality should be housed in its own
> dedicated, small, reusable package. Any projects that require URI,
URL
> or URN functionality can do so by importing a small, focused
package,
> commons-uri.jar.
>
> (1) scope of the package
>
> The package shall provide a complete java implementation of RFC2396.
> This includes the URI as well as URL and URN classes and utilities.
> The implementation will be fully character set aware.
>
> (1.5) interaction with other packages
>
> Have no dependancies beyond the standard java packages.
>
> *
>
> (2) identify the initial source for the packages
>
> Various classes in common from from Commons HttpClient Jakarta
Slide.
>
> (2.1) identify the base name for the package
>
> org.apache.commons.uri
>
> (2.2) identify the coding conventions for this package
>
> The code uses the conventions from the Jakarta Commons.
>
> (2.1) Identify the initial file structure
>
> jakarta-commons/org/apache/commons/uri
>
> uri/
> URI.java
> URIUtil.java
> URIException.java
> url/
> HttpsURL.java
> HttpURL.java
> urn/
>
> (3) identify any Jakarta-Commons resources to be created
>
> (3.1) mailing list
>
> commons-dev@jakarta.apache.org
>
> (3.2) CVS repositories
>
> jakarta-commons/uri
>
> (3.3) Bugzilla
>
> The package should be listed as the uri component under the
> Jakarta-Commons Bugzilla entry.
>
> (4) identify the initial set of committers to be listed in the
Status File.
>
> Jeff Dever (jsdever)
> Sung-Gu Park (jericho)
> others?
>
>
>
>
> --------------------------------------------------------------------
-
> To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
>
>
>