You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Adrian Sutton <ad...@intencha.com> on 2004/03/17 08:35:06 UTC
[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 httpclient@jakarta.apache.org mailing list or a
httpclient-dev@jakarta.apahce.org 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:
httpclient@jakarta.apache.org 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Posted by Michael Becke <be...@u.washington.edu>.
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 httpclient@jakarta.apache.org mailing
> list or a
> httpclient-dev@jakarta.apahce.org 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:
> httpclient@jakarta.apache.org 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:
> 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: [PROPOSAL][DRAFT] Promote HttpClient to Jakarta level
Posted by Roland Weber <RO...@de.ibm.com>.
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