Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
The proposal looks good to me. I think we are ready for a vote. Mike On Mar 23, 2004, at 11:25 PM, Adrian Sutton wrote: Hi all, Are there any further comments on this or are we ready to put it to a vote? I have not had any response from any of the inactive committers and figure a week is long enough to wait. They can of course be reinstated as a committer at any time in the future by just requesting it (and sorting out the CLA if need be). The proposal below is unchanged from the last draft with the only suggested change being moving the dependency to Java 1.3 - the consensus seems to be that there's no real cause for dropping Java 1.2 support at this stage. If there are no further suggestions I'll get a vote thread started in the next couple of days. Regards, Adrian Sutton. (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 2616 and RFC 2617. HttpClient also supports the following RFCs. * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade to RFC 2965 is planned for a future version of HttpClient * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax * RFC 1867 Form-based File Upload in HTML The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by a wide range of projects both within the ASF and from third parties. These include: * Jakarta Slide * Jakarta Commons Latka * Nortel Networks * HtmlUnit * Jakarta Cactus * JSR 147 * NOSE Applied Intelligence ag * MindIQ's Design-a-Course * ContactOffice * Newknow * de4d2c * Furies * Term Highlighting for Verity Ultraseek search results * Mule - Universal Message Objects * many more. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) * Jakarta commons-logging (Version 1.0 or later) * Jakarta commons-codec (Version 1.2 or later) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - Two new mailing lists will be required: [EMAIL PROTECTED] and [EMAIL PROTECTED] These will be used for developer discussions and user discussions respectively. CVS commit messages will be sent to the httpclient-dev list. * Bugzilla - New product category "HttpClient", with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Oleg Kalnichevski * Adrian Sutton -- Intencha "tomorrow's technology today" Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hi all, Are there any further comments on this or are we ready to put it to a vote? I have not had any response from any of the inactive committers and figure a week is long enough to wait. They can of course be reinstated as a committer at any time in the future by just requesting it (and sorting out the CLA if need be). The proposal below is unchanged from the last draft with the only suggested change being moving the dependency to Java 1.3 - the consensus seems to be that there's no real cause for dropping Java 1.2 support at this stage. If there are no further suggestions I'll get a vote thread started in the next couple of days. Regards, Adrian Sutton. > > (0) RATIONALE > HTTP is the main protocol used today on the internet. Although the JDK > includes basic support for building HTTP-aware client applications, it > doesn't provide the flexibility or ease of use needed for many projects. > > The current package in Jakarta-Commons is a widely used implementation with > a strong community behind it. The size of it's community and it's project > has significantly outgrown the commons project and a move to a Jakarta level > project would provide better support for that community and for the on going > development of HttpClient. > > (1) SCOPE > The project shall create and maintain a Java library implementing the client > side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 2616 and > RFC 2617. > > HttpClient also supports the following RFCs. > > * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade to RFC > 2965 is planned for a future version of HttpClient > > * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax > > * RFC 1867 Form-based File Upload in HTML > > The package should: > > * Have an API which should be as simple to use as possible > * Be as easy to extend as possible > * Provide unconditional support for HTTP/1.1 > > The package is quite different from the HTTP client provided as part of the > JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being > sent (instead of making that transparent to the user), and generally allows > more interaction with the lower level connection. The JDK client is also > not very intuitive to use. > > The package is used by a wide range of projects both within the ASF and from > third parties. These include: > > * Jakarta Slide > * Jakarta Commons Latka > * Nortel Networks > * HtmlUnit > * Jakarta Cactus > * JSR 147 > * NOSE Applied Intelligence ag > * MindIQ's Design-a-Course > * ContactOffice > * Newknow > * de4d2c > * Furies > * Term Highlighting for Verity Ultraseek search results > * Mule - Universal Message Objects > * many more. > > (1.5) Interaction With Other Packages > > HttpClient relies on: > > * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) > * Jakarta commons-logging (Version 1.0 or later) > * Jakarta commons-codec (Version 1.2 or later) > > (2) INITIAL SOURCE OF THE PACKAGE > > The initial codebase exists as a sub-project of Jakarta-Commons, in the > httpclient subdirectory of the jakarta-commons cvs tree. > > The proposed package name for the new sub-project is org.apache.httpclient. > > (3) REQUIRED JAKARTA RESOURCES > > * CVS Repository - New module, jakarta-httpclient in the CVS repository. > > * Initial Committers - The list is provided below. All of the proposed > committers are currently jakarta-commons committers. > > * Mailing List - Two new mailing lists will be required: > [EMAIL PROTECTED] and [EMAIL PROTECTED] > These will be used for developer discussions and user discussions > respectively. CVS commit messages will be sent to the httpclient-dev list. > > * Bugzilla - New product category "HttpClient", with appropriate version > identifiers as needed. Existing bugs in the HttpClient component under the > Commons product category will need to be migrated. > > (4) INITIAL COMMITTERS > The initial committers on the HttpClient component shall be: > > * Michael Becke > * Jeff Dever > * dIon Gillard > * Ortwin Glück > * Oleg Kalnichevski > * Adrian Sutton -- Intencha "tomorrow's technology today" Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Oleg wrote: > I really think Java 1.3 does not bring anything > to the table as far as HTTP communication is concerned. Ok, I agree. Just wanted to make sure we didn't miss a chance. cheers, Roland
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Yes, 1.3 doesn't bring us much. I think we should stick with 1.2 until
we are ready for 1.4. As Oleg suggested, this probably won't happen
for some time.
Mike
On Mar 18, 2004, at 7:51 AM, Roland Weber wrote:
Hello Adrian,
there is reflections stuff in:
HttpConnection -> check for 1.3
HttpException -> check for 1.4
util/ExceptionUtil -> check for 1.4
You're right, if getting rid of the reflections
in HttpConnection is the only improvement,
there is no point in requiring JDK 1.3.
Does anyone else know about other parts of
the code where you would have liked to use
some 1.3 functionality? Improved collection
classes or so?
cheers,
Roland
Adrian Sutton <[EMAIL PROTECTED]>
18.03.2004 13:27
Please respond to "Commons HttpClient Project"
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
cc:
Subject: Re: [PROPOSAL][DRAFT] Promote HttpClient to
Jakarta level
On 18/3/04 10:24 PM, "Roland Weber" <[EMAIL PROTECTED]> wrote:
(1.5) Interaction With Other Packages
HttpClient relies on:
* Java Development Kit (Version 1.2 or later; 1.3 or later
recommended)
I wonder whether this would be the right time
to drop support for JDK 1.2 and require 1.3 ?
I generally find the right time is when there's a good reason to. Was
there
a 1.3 only method we wanted to use? I know 1.4 has some cool stuff but
we're not going to be getting to use that for quite some time yet.
cheers,
Roland
Regards,
Adrian Sutton.
===
Kangaroo Point MarchFest is an annual festival of music, art, food and
culture, that aims to build community spirit and bring all types of
people together for a time of fun and entertainment.
Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church.
http://www.soulpurpose.com.au/marchfest
===
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
--- Begin Message ---
(Some went badly wrong with my previous message. Damn Outlook. Retrying)
Folks,
I really think Java 1.3 does not bring anything to the table as far as HTTP
communication is concerned. I am not even sure you we need Socket#shutdownOutput() at
all. Currently HttpConnection#shutdownOutput is not used anywhere in HttpClient.
Java 1.4 is a totally different story. I've recently delved into New I/O and am
convinced it would make a lot of sense for us if we do not use multiplexed I/O. New
buffering primitives in java.nio package can drastically decrease object garbage
collection and improve I/O buffering.
This said, I do believe that Java 1.4 dependency is a little premature at this point.
Upgrade to Java 1.4 should probably coincide with the 4.0 API redesign
Oleg
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Thu 3/18/2004 13:51
To: Commons HttpClient Project
Cc:
Subject:Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hello Adrian,
there is reflections stuff in:
HttpConnection -> check for 1.3
HttpException -> check for 1.4
util/ExceptionUtil -> check for 1.4
You're right, if getting rid of the reflections
in HttpConnection is the only improvement,
there is no point in requiring JDK 1.3.
Does anyone else know about other parts of
the code where you would have liked to use
some 1.3 functionality? Improved collection
classes or so?
cheers,
Roland
Adrian Sutton <[EMAIL PROTECTED]>
18.03.2004 13:27
Please respond to "Commons HttpClient Project"
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
cc:
Subject:Re: [PROPOSAL][DRAFT] Promote HttpClient to
Jakarta level
On 18/3/04 10:24 PM, "Roland Weber" <[EMAIL PROTECTED]> wrote:
>> (1.5) Interaction With Other Packages
>>
>> HttpClient relies on:
>>
>> * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
>
> I wonder whether this would be the right time
> to drop support for JDK 1.2 and require 1.3 ?
I generally find the right time is when there's a good reason to. Was
there
a 1.3 only method we wanted to use? I know 1.4 has some cool stuff but
we're not going to be getting to use that for quite some time yet.
> cheers,
> Roland
Regards,
Adrian Sutton.
===
Kangaroo Point MarchFest is an annual festival of music, art, food and
culture, that aims to build community spirit and bring all types of
people together for a time of fun and entertainment.
Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church.
http://www.soulpurpose.com.au/marchfest
===
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
<>--- End Message ---
***
The information in this email is confidential and may be legally privileged. Access
to this email by anyone other than the intended addressee is unauthorized. If you are
not the intended recipient of this message, any review, disclosure, copying,
distribution, retention, or any action taken or omitted to be taken in reliance on it
is prohibited and may be unlawful. If you are not the intended recipient, please
reply to or forward a copy of this message to the sender and delete the message, any
attachments, and any copies thereof from your system.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
--- Begin Message ---
Folks,
I really think Java 1.3 does not bring anything to the table as far as HTTP
communication is concerned. I am not even sure you we need Socket#shutdownOutput() at
all. Currently HttpConnection#shutdownOutput is not used anywhere in HttpClient.
Java 1.4 is a totally different story. I've recently delved into New I/O and am
convinced it would make a lot of sense for us if we do not use multiplexed I/O. New
buffering primitives in java.nio package can drastically decrease object garbage
collection and improve I/O buffering.
This said, I do believe that Java 1.4 dependency is a little premature at this point.
Upgrade to Java 1.4 should probably coincide with the 4.0 API redesign
Oleg
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Thu 3/18/2004 13:51
To: Commons HttpClient Project
Cc:
Subject:Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hello Adrian,
there is reflections stuff in:
HttpConnection -> check for 1.3
HttpException -> check for 1.4
util/ExceptionUtil -> check for 1.4
You're right, if getting rid of the reflections
in HttpConnection is the only improvement,
there is no point in requiring JDK 1.3.
Does anyone else know about other parts of
the code where you would have liked to use
some 1.3 functionality? Improved collection
classes or so?
cheers,
Roland
Adrian Sutton <[EMAIL PROTECTED]>
18.03.2004 13:27
Please respond to "Commons HttpClient Project"
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
cc:
Subject:Re: [PROPOSAL][DRAFT] Promote HttpClient to
Jakarta level
On 18/3/04 10:24 PM, "Roland Weber" <[EMAIL PROTECTED]> wrote:
>> (1.5) Interaction With Other Packages
>>
>> HttpClient relies on:
>>
>> * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
>
> I wonder whether this would be the right time
> to drop support for JDK 1.2 and require 1.3 ?
I generally find the right time is when there's a good reason to. Was
there
a 1.3 only method we wanted to use? I know 1.4 has some cool stuff but
we're not going to be getting to use that for quite some time yet.
> cheers,
> Roland
Regards,
Adrian Sutton.
===
Kangaroo Point MarchFest is an annual festival of music, art, food and
culture, that aims to build community spirit and bring all types of
people together for a time of fun and entertainment.
Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church.
http://www.soulpurpose.com.au/marchfest
===
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
<>--- End Message ---
***
The information in this email is confidential and may be legally privileged. Access
to this email by anyone other than the intended addressee is unauthorized. If you are
not the intended recipient of this message, any review, disclosure, copying,
distribution, retention, or any action taken or omitted to be taken in reliance on it
is prohibited and may be unlawful. If you are not the intended recipient, please
reply to or forward a copy of this message to the sender and delete the message, any
attachments, and any copies thereof from your system.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hello Adrian,
there is reflections stuff in:
HttpConnection -> check for 1.3
HttpException -> check for 1.4
util/ExceptionUtil -> check for 1.4
You're right, if getting rid of the reflections
in HttpConnection is the only improvement,
there is no point in requiring JDK 1.3.
Does anyone else know about other parts of
the code where you would have liked to use
some 1.3 functionality? Improved collection
classes or so?
cheers,
Roland
Adrian Sutton <[EMAIL PROTECTED]>
18.03.2004 13:27
Please respond to "Commons HttpClient Project"
To: Commons HttpClient Project
<[EMAIL PROTECTED]>
cc:
Subject: Re: [PROPOSAL][DRAFT] Promote HttpClient to
Jakarta level
On 18/3/04 10:24 PM, "Roland Weber" <[EMAIL PROTECTED]> wrote:
>> (1.5) Interaction With Other Packages
>>
>> HttpClient relies on:
>>
>> * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
>
> I wonder whether this would be the right time
> to drop support for JDK 1.2 and require 1.3 ?
I generally find the right time is when there's a good reason to. Was
there
a 1.3 only method we wanted to use? I know 1.4 has some cool stuff but
we're not going to be getting to use that for quite some time yet.
> cheers,
> Roland
Regards,
Adrian Sutton.
===
Kangaroo Point MarchFest is an annual festival of music, art, food and
culture, that aims to build community spirit and bring all types of
people together for a time of fun and entertainment.
Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church.
http://www.soulpurpose.com.au/marchfest
===
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
On 18/3/04 10:24 PM, "Roland Weber" <[EMAIL PROTECTED]> wrote: >> (1.5) Interaction With Other Packages >> >> HttpClient relies on: >> >> * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) > > I wonder whether this would be the right time > to drop support for JDK 1.2 and require 1.3 ? I generally find the right time is when there's a good reason to. Was there a 1.3 only method we wanted to use? I know 1.4 has some cool stuff but we're not going to be getting to use that for quite some time yet. > cheers, > Roland Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
> (1.5) Interaction With Other Packages > > HttpClient relies on: > > * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) I wonder whether this would be the right time to drop support for JDK 1.2 and require 1.3 ? cheers, Roland
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hi all, Here's the updated proposal as promised. A change log is below: * Removed Sean C. Sullivan and Sung-Gu from the list of committers due to them not having a CLA on file. The email address for both these people is their @apache.org address. I've attempted to contact them at those addresses but I imagine they will have been disabled. * Removed Rodney Waldhoff from the list of committers pending his notification that he'd like to remain with the project. I have contacted him off list about this just now and he will be immediately readded if he wishes to be. All other committers voted on the proposal to move to Jakarta and so I assume to be still with the project. If anyone "wants out", please let me know. * Changed to having separate lists for user and dev, with CVS commit messages going to the dev list. * Added commons-logging and commons-codec to the list of dependencies. * Updated list of RFCs implemented to match the current list on the website. * Updated list of projects using HttpClient to match those on the applications page of the website. I'm wondering if we now list too many. Should we just have a statement to the effect that a wide range of projects depend on HttpClient or should we actually list the ones we've been told about? I think that was all the requests that came in. Let me know if I missed something and as always comments and criticisms are encouraged. Regards, Adrian Sutton. (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 2616 and RFC 2617. HttpClient also supports the following RFCs. * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade to RFC 2965 is planned for a future version of HttpClient * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax * RFC 1867 Form-based File Upload in HTML The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by a wide range of projects both within the ASF and from third parties. These include: * Jakarta Slide * Jakarta Commons Latka * Nortel Networks * HtmlUnit * Jakarta Cactus * JSR 147 * NOSE Applied Intelligence ag * MindIQ's Design-a-Course * ContactOffice * Newknow * de4d2c * Furies * Term Highlighting for Verity Ultraseek search results * Mule - Universal Message Objects * many more. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) * Jakarta commons-logging (Version 1.0 or later) * Jakarta commons-codec (Version 1.2 or later) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - Two new mailing lists will be required: [EMAIL PROTECTED] and [EMAIL PROTECTED] These will be used for developer discussions and user discussions respectively. CVS commit messages will be sent to the httpclient-dev list. * Bugzilla - New product category "HttpClient", with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Oleg Kalnichevski * Adrian Sutton === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
On 18/3/04 12:54 AM, "Jeff Dever" <[EMAIL PROTECTED]> wrote: > Just the active ones. You must leave off Sun-gu and Sean, since they > don't have CLA on file their committer status has been suspended. I > agree with Oleg about the handling of the others. Sounds good to me. I'll take care of chasing down the committers that are in the current draft proposal this afternoon. I'll also do up a second draft proposal with the feedback I've received. Thanks for all the feedback. > -jsd Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Just the active ones. You must leave off Sun-gu and Sean, since they don't have CLA on file their committer status has been suspended. I agree with Oleg about the handling of the others. -jsd Should all the committers come across or just the currently active ones? I think this should be all of them, in which case - should we attempt to contact them and ask for their preference? I've currently taken the list from project.xml. The trouble is that 2 of our committers turned out to have not signed the Apache CLA. Some of people included have officially resigned from the project. Some have not been showing up for years. To be fair to ourselves and the PMC who is going to vote on the proposal, I think we should include only active committers. As to currently inactive committers, we should inform them about the move and change of the project status. If they express their willingness to resume/continue working on the project, once the legal aspects are taken care of, their full-fledged committer status can be unconditionally restored. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Sweet!! Thank you for getting started on this. Definitely no toes being stepped on here. I would like to echo Oleg and Roland's comments. In particular I think having separate user and dev mailing lists in a good idea. Given that, CVS logs should probably just go to dev. In the "(1.5) Interaction With Other Packages" section we should probably also include commons-logging and commons-codec. Mike On Mar 17, 2004, at 2:35 AM, Adrian Sutton wrote: Hi all, I thought I'd get the ball rolling on creating this proposal - sorry if I've stepped on someone's toes. I had a few unexpected spare cycles. From http://jakarta.apache.org/site/management.html our Proposal needs to have the following things: Scope of the Project Initial source from which the project is to be populated Identify the mailing lists if any to be created Identify the initial set of committers Questions that I can see (all fairly trivial): Should we create a separate dev and user mailing list? If not should we just have a [EMAIL PROTECTED] mailing list or a [EMAIL PROTECTED] mailing list? Should we have a separate list for CVS commit messages? These generally go to the dev list which is good for oversight but it may be a bit much if it's a combined dev/user list. Should all the committers come across or just the currently active ones? I think this should be all of them, in which case - should we attempt to contact them and ask for their preference? I've currently taken the list from project.xml. What's a Jyve FAQ (we requested one in our initial proposal) and are we still using it? Has anyone noticed that our current proposal includes: "The initial committers on the Digester component shall be:..." (note Digester instead of HttpClient). I guess it's bad form to go back and change that now. Here's what I've come up with basically from just updating the current Proposal to be Jakarta level instead of Commons level. Thoughts, comments, criticisms and generally tearing all this to shreds would be appreciated. Regards, Adrian Sutton. - (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP/1.1 protocol, as defined in RFC 2616 and RFC 2617. The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by the Slide proejcct to build a WebDAV client library supporting WebDAV level 2. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - A new mailing list will be required: [EMAIL PROTECTED] Both user and development discussions will take place on this list. * Bugzilla - New product category "HttpClient", with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Sung-Gu * Oleg Kalnichevski * Sean C. Sullivan * Adrian Sutton * Rodney Waldhoff === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest ==
RE: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hi Adrian > Should we create a separate dev and user mailing list? > If not should we just have a [EMAIL PROTECTED] mailing list or a > [EMAIL PROTECTED] mailing list? I think we should have separate httpclient-dev and httpclient-user lists. It is a common practice for many (if not all) Jakarta projects. > Should all the committers come across or just the currently active ones? I > think this should be all of them, in which case - should we attempt to > contact them and ask for their preference? I've currently taken the list > from project.xml. The trouble is that 2 of our committers turned out to have not signed the Apache CLA. Some of people included have officially resigned from the project. Some have not been showing up for years. To be fair to ourselves and the PMC who is going to vote on the proposal, I think we should include only active committers. As to currently inactive committers, we should inform them about the move and change of the project status. If they express their willingness to resume/continue working on the project, once the legal aspects are taken care of, their full-fledged committer status can be unconditionally restored. > The project shall create and maintain a Java library implementing the client > side of the HTTP/1.1 protocol, as defined in RFC 2616 and RFC 2617. There are a few more RFCs to be mentioned: RFC2109 (upgrade to 2965 planned for 4.0), RFC1867, RFC2396. RFC1945 compatibility should be mentioned as well. > The package is used by the Slide proejcct to build a WebDAV client library > supporting WebDAV level 2. HttpClient is now used by many other Apache projects (Cactus, XML-RPC to mention a few) besides Slide and non-Apache projects (Limewire, JBoss, as it recently turned out). I believe this fact should be mentioned as evidence of HttpClient growing acceptance beyond its original user base thus supporting out bid for promotion from Jakarta Commons to Jakarta proper. Oleg -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 8:35 To: Commons HttpClient Project Subject: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level Hi all, I thought I'd get the ball rolling on creating this proposal - sorry if I've stepped on someone's toes. I had a few unexpected spare cycles. >From http://jakarta.apache.org/site/management.html our Proposal needs to have the following things: Scope of the Project Initial source from which the project is to be populated Identify the mailing lists if any to be created Identify the initial set of committers Questions that I can see (all fairly trivial): Should we create a separate dev and user mailing list? If not should we just have a [EMAIL PROTECTED] mailing list or a [EMAIL PROTECTED] mailing list? Should we have a separate list for CVS commit messages? These generally go to the dev list which is good for oversight but it may be a bit much if it's a combined dev/user list. Should all the committers come across or just the currently active ones? I think this should be all of them, in which case - should we attempt to contact them and ask for their preference? I've currently taken the list from project.xml. What's a Jyve FAQ (we requested one in our initial proposal) and are we still using it? Has anyone noticed that our current proposal includes: "The initial committers on the Digester component shall be:..." (note Digester instead of HttpClient). I guess it's bad form to go back and change that now. Here's what I've come up with basically from just updating the current Proposal to be Jakarta level instead of Commons level. Thoughts, comments, criticisms and generally tearing all this to shreds would be appreciated. Regards, Adrian Sutton. - (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP/1.1 protocol, as defined in RFC 2616 and RFC 2617. The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally a
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hello Adrian, I'd add at least RFC 2965: Http State Management (Cookies) to the scope. The biggest problems I had with HttpClient is that the cookie functionality is an almost inseparable part, whereas I needed HTTP without the cookie stuff. I feel it is important to distinguish the cookie handling from the pure HTTP functionality. cheers, Roland
[PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Hi all, I thought I'd get the ball rolling on creating this proposal - sorry if I've stepped on someone's toes. I had a few unexpected spare cycles. >From http://jakarta.apache.org/site/management.html our Proposal needs to have the following things: Scope of the Project Initial source from which the project is to be populated Identify the mailing lists if any to be created Identify the initial set of committers Questions that I can see (all fairly trivial): Should we create a separate dev and user mailing list? If not should we just have a [EMAIL PROTECTED] mailing list or a [EMAIL PROTECTED] mailing list? Should we have a separate list for CVS commit messages? These generally go to the dev list which is good for oversight but it may be a bit much if it's a combined dev/user list. Should all the committers come across or just the currently active ones? I think this should be all of them, in which case - should we attempt to contact them and ask for their preference? I've currently taken the list from project.xml. What's a Jyve FAQ (we requested one in our initial proposal) and are we still using it? Has anyone noticed that our current proposal includes: "The initial committers on the Digester component shall be:..." (note Digester instead of HttpClient). I guess it's bad form to go back and change that now. Here's what I've come up with basically from just updating the current Proposal to be Jakarta level instead of Commons level. Thoughts, comments, criticisms and generally tearing all this to shreds would be appreciated. Regards, Adrian Sutton. - (0) RATIONALE HTTP is the main protocol used today on the internet. Although the JDK includes basic support for building HTTP-aware client applications, it doesn't provide the flexibility or ease of use needed for many projects. The current package in Jakarta-Commons is a widely used implementation with a strong community behind it. The size of it's community and it's project has significantly outgrown the commons project and a move to a Jakarta level project would provide better support for that community and for the on going development of HttpClient. (1) SCOPE The project shall create and maintain a Java library implementing the client side of the HTTP/1.1 protocol, as defined in RFC 2616 and RFC 2617. The package should: * Have an API which should be as simple to use as possible * Be as easy to extend as possible * Provide unconditional support for HTTP/1.1 The package is quite different from the HTTP client provided as part of the JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods being sent (instead of making that transparent to the user), and generally allows more interaction with the lower level connection. The JDK client is also not very intuitive to use. The package is used by the Slide proejcct to build a WebDAV client library supporting WebDAV level 2. (1.5) Interaction With Other Packages HttpClient relies on: * Java Development Kit (Version 1.2 or later; 1.3 or later recommended) (2) INITIAL SOURCE OF THE PACKAGE The initial codebase exists as a sub-project of Jakarta-Commons, in the httpclient subdirectory of the jakarta-commons cvs tree. The proposed package name for the new sub-project is org.apache.httpclient. (3) REQUIRED JAKARTA RESOURCES * CVS Repository - New module, jakarta-httpclient in the CVS repository. * Initial Committers - The list is provided below. All of the proposed committers are currently jakarta-commons committers. * Mailing List - A new mailing list will be required: [EMAIL PROTECTED] Both user and development discussions will take place on this list. * Bugzilla - New product category "HttpClient", with appropriate version identifiers as needed. Existing bugs in the HttpClient component under the Commons product category will need to be migrated. (4) INITIAL COMMITTERS The initial committers on the HttpClient component shall be: * Michael Becke * Jeff Dever * dIon Gillard * Ortwin Glück * Sung-Gu * Oleg Kalnichevski * Sean C. Sullivan * Adrian Sutton * Rodney Waldhoff === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
