You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Henri Yandell <ba...@generationjava.com> on 2005/09/24 23:55:24 UTC
[Request for Comment] Http Components proposal
Prior to calling a PMC vote here in a week or two, I'd like to ask if
anybody has any comments on the following proposal for Commons
HttpClient to become a Jakarta subproject focusing on Http components.
Hen
*********************************************************************
(The following charter for Jakarta Http Components project is pending
approval of the Jakarta Project Management Committee (PMC). )
Rationale:
=========
The original Jakarta Commons HttpClient API has a number limitations that
cannot be resolved without a significant architectural redesign. Moreover,
Jakarta Commons HttpClient has been increasingly used in applications and
environments it has not been specifically designed for. The existing
monolithic design no longer adequately reflects the use patterns of
HttpClient.
HttpClient needs to be refactored into a toolset of simple, low level HTTP
components suitable for building more specialized HTTP services.
Project scope:
=============
* Jakarta Http Components develops a toolset of low level components
focused exclusively at the transport aspects of HTTP protocol.
* Jakarta Http Components MUST be content agnostic. The project DOES NOT
develop components intended to produce or consume content of HTTP
messages.
* Jakarta Http Components continues the development of Jakarta
HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
HTTP components. This tool focuses strictly on the client side of HTTP.
* Jakarta Http Components MAY develop non-client components (such as an
HTTP connector, a lightweight server component, proxy components) as
reference material to demonstrate the capabilities of the toolset. The
said artifacts ARE NOT meant for production use and are not released as
official Apache Jakarta products.
* Jakarta Http Components collaborates with other projects to develop
specialized HTTP services for production use based on the toolset of HTTP
components.
* Jakarta Http Components DOES NOT define a server side API on top of the
low level transport API.
Targeted specifications and standards:
=====================================
* RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
* RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
* RFC2617 HTTP Authentication: Basic and Digest Access Authentication
* RFC2109 HTTP State Management Mechanism -- Cookies
* RFC2965 HTTP State Management Mechanism -- Cookie2
* A standard for robot exclusion - robots.txt parser (contribution requiring Software Grant - http://www.osjava.org/norbert/)
Initial set of committers:
==========================
Project Lead
Michael Becke
Project Committers
Adrian Sutton
Ortwin Glueck
Oleg Kalnichevski
Henri Yandell
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, Sep 26, 2005 at 11:06:58AM -0400, Henri Yandell wrote:
>
>
> On Mon, 26 Sep 2005, Oleg Kalnichevski wrote:
>
> >On Sun, Sep 25, 2005 at 11:30:02PM +0100, robert burrell donkin wrote:
> >>
> >>IMHO if this is the vision then it would be better to rephrase the final
> >>clause to make this clear. maybe something like:
> >>
> >>* Jakarta Http Components will provide ONLY a toolset of low level
> >>generic transport APIs. In particular, server side application layer
> >>APIs WILL NOT be developed.
> >>
> >
> >This does sound much better. If there are no objections, I would like to
> >update the charter draft and replace the original clause with the one
> >suggested by Robert.
>
> None from me; go ahead and drop us the link to the Wiki (because I didn't
> include it in the original like a fool :) ).
>
Here's the link to the wiki based draft:
http://wiki.apache.org/jakarta-httpclient/NewProjectCharter?action=show
Oleg
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 26 Sep 2005, Oleg Kalnichevski wrote:
> On Sun, Sep 25, 2005 at 11:30:02PM +0100, robert burrell donkin wrote:
>>
>> IMHO if this is the vision then it would be better to rephrase the final
>> clause to make this clear. maybe something like:
>>
>> * Jakarta Http Components will provide ONLY a toolset of low level
>> generic transport APIs. In particular, server side application layer
>> APIs WILL NOT be developed.
>>
>
> This does sound much better. If there are no objections, I would like to
> update the charter draft and replace the original clause with the one
> suggested by Robert.
None from me; go ahead and drop us the link to the Wiki (because I didn't
include it in the original like a fool :) ).
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, Sep 25, 2005 at 11:30:02PM +0100, robert burrell donkin wrote:
> On Sun, 2005-09-25 at 12:27 +0200, Oleg Kalnichevski wrote:
> > On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote:
> > > On 9/24/05, Henri Yandell <ba...@generationjava.com> wrote:
> > ...
> > > > * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> > > > develop components intended to produce or consume content of HTTP
> > > > messages.
> > >
> > >
> > > While I understand what you're trying to say here, this wording appears to
> > > preclude some of what is in HttpClient today, namely multipart content
> > > handling.
> > >
> >
> > Hi Martin,
> >
> > This statement is not accidental. The plan is to factor the multipart
> > content handling out of HttpClient. There's already a project in Commons
> > Sandbox led by Mark R. Diggory
> > <http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/> for that end.
> > Unfortunately the project has been dormant for quite some time but the plan is to revive
> > the project at some point, get it graduate from Sandbox and possibly get it merged with
> > Commons Codec proper at some point of time.
>
> IMHO a clause need to be inserted to allow the sub-project maintain the
> existing codebase (since it will be out-of-scope otherwise). actually,
> i'd prefer to see the pmc give the explicit responsibility for
> maintenance to the sub-project.
>
> > > > * Jakarta Http Components DOES NOT define a server side API on top of the
> > > > low level transport API.
> > >
> > >
> > > Again, I understand what you want to say. However, I think it would be
> > > better said in terms that make it clear that it is intended for use on the
> > > client side _of the protocol_, since many people are using HttpClient on the
> > > server side today, but as a client to other servers.
> > >
> >
> > Actually we see more and more often HttpClient code used to implement
> > server side of the protocol as well. This statement is primarily to
> > ensure that the project will not sidetrack into developing and
> > _application_ API competing with javax.servlet API. We merely want to
> > provide low level generic transport primitives.
>
> IMHO if this is the vision then it would be better to rephrase the final
> clause to make this clear. maybe something like:
>
> * Jakarta Http Components will provide ONLY a toolset of low level
> generic transport APIs. In particular, server side application layer
> APIs WILL NOT be developed.
>
This does sound much better. If there are no objections, I would like to
update the charter draft and replace the original clause with the one
suggested by Robert.
Oleg
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: [Request for Comment] Http Components proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The plan is to factor the multipart content handling out
> of HttpClient. There's already a project in Commons
> Sandbox led by Mark R. Diggory [for] that end. Unfortunately
> the project has been dormant for quite some time
See also: http://svn.apache.org/repos/asf/james/mime4j
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-09-25 at 12:27 +0200, Oleg Kalnichevski wrote:
> On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote:
> > On 9/24/05, Henri Yandell <ba...@generationjava.com> wrote:
> ...
> > > * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> > > develop components intended to produce or consume content of HTTP
> > > messages.
> >
> >
> > While I understand what you're trying to say here, this wording appears to
> > preclude some of what is in HttpClient today, namely multipart content
> > handling.
> >
>
> Hi Martin,
>
> This statement is not accidental. The plan is to factor the multipart
> content handling out of HttpClient. There's already a project in Commons
> Sandbox led by Mark R. Diggory
> <http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/> for that end.
> Unfortunately the project has been dormant for quite some time but the plan is to revive
> the project at some point, get it graduate from Sandbox and possibly get it merged with
> Commons Codec proper at some point of time.
IMHO a clause need to be inserted to allow the sub-project maintain the
existing codebase (since it will be out-of-scope otherwise). actually,
i'd prefer to see the pmc give the explicit responsibility for
maintenance to the sub-project.
> > > * Jakarta Http Components DOES NOT define a server side API on top of the
> > > low level transport API.
> >
> >
> > Again, I understand what you want to say. However, I think it would be
> > better said in terms that make it clear that it is intended for use on the
> > client side _of the protocol_, since many people are using HttpClient on the
> > server side today, but as a client to other servers.
> >
>
> Actually we see more and more often HttpClient code used to implement
> server side of the protocol as well. This statement is primarily to
> ensure that the project will not sidetrack into developing and
> _application_ API competing with javax.servlet API. We merely want to
> provide low level generic transport primitives.
IMHO if this is the vision then it would be better to rephrase the final
clause to make this clear. maybe something like:
* Jakarta Http Components will provide ONLY a toolset of low level
generic transport APIs. In particular, server side application layer
APIs WILL NOT be developed.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote:
> On 9/24/05, Henri Yandell <ba...@generationjava.com> wrote:
...
> > * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> > develop components intended to produce or consume content of HTTP
> > messages.
>
>
> While I understand what you're trying to say here, this wording appears to
> preclude some of what is in HttpClient today, namely multipart content
> handling.
>
Hi Martin,
This statement is not accidental. The plan is to factor the multipart
content handling out of HttpClient. There's already a project in Commons
Sandbox led by Mark R. Diggory
<http://svn.apache.org/repos/asf/jakarta/commons/dormant/codec-multipart/> for that end. Unfortunately the project has been dormant for quite some time but the plan is to revive the project at some point, get it graduate from Sandbox and possibly get it merged with Commons Codec proper at some point of time.
> > * Jakarta Http Components DOES NOT define a server side API on top of the
> > low level transport API.
>
>
> Again, I understand what you want to say. However, I think it would be
> better said in terms that make it clear that it is intended for use on the
> client side _of the protocol_, since many people are using HttpClient on the
> server side today, but as a client to other servers.
>
Actually we see more and more often HttpClient code used to implement
server side of the protocol as well. This statement is primarily to
ensure that the project will not sidetrack into developing and
_application_ API competing with javax.servlet API. We merely want to
provide low level generic transport primitives.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Martin Cooper <mf...@gmail.com>.
On 9/24/05, Henri Yandell <ba...@generationjava.com> wrote:
>
>
> Prior to calling a PMC vote here in a week or two, I'd like to ask if
> anybody has any comments on the following proposal for Commons
> HttpClient to become a Jakarta subproject focusing on Http components.
>
> Hen
>
> *********************************************************************
>
> (The following charter for Jakarta Http Components project is pending
> approval of the Jakarta Project Management Committee (PMC). )
>
> Rationale:
> =========
>
> The original Jakarta Commons HttpClient API has a number limitations that
> cannot be resolved without a significant architectural redesign. Moreover,
> Jakarta Commons HttpClient has been increasingly used in applications and
> environments it has not been specifically designed for. The existing
> monolithic design no longer adequately reflects the use patterns of
> HttpClient.
>
> HttpClient needs to be refactored into a toolset of simple, low level HTTP
> components suitable for building more specialized HTTP services.
>
> Project scope:
> =============
>
> * Jakarta Http Components develops a toolset of low level components
> focused exclusively at the transport aspects of HTTP protocol.
>
> * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> develop components intended to produce or consume content of HTTP
> messages.
While I understand what you're trying to say here, this wording appears to
preclude some of what is in HttpClient today, namely multipart content
handling.
* Jakarta Http Components continues the development of Jakarta
> HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
> HTTP components. This tool focuses strictly on the client side of HTTP.
>
> * Jakarta Http Components MAY develop non-client components (such as an
> HTTP connector, a lightweight server component, proxy components) as
> reference material to demonstrate the capabilities of the toolset. The
> said artifacts ARE NOT meant for production use and are not released as
> official Apache Jakarta products.
>
> * Jakarta Http Components collaborates with other projects to develop
> specialized HTTP services for production use based on the toolset of HTTP
> components.
>
> * Jakarta Http Components DOES NOT define a server side API on top of the
> low level transport API.
Again, I understand what you want to say. However, I think it would be
better said in terms that make it clear that it is intended for use on the
client side _of the protocol_, since many people are using HttpClient on the
server side today, but as a client to other servers.
--
Martin Cooper
Targeted specifications and standards:
> =====================================
> * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
> * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
> * RFC2617 HTTP Authentication: Basic and Digest Access Authentication
> * RFC2109 HTTP State Management Mechanism -- Cookies
> * RFC2965 HTTP State Management Mechanism -- Cookie2
> * A standard for robot exclusion - robots.txt parser (contribution
> requiring Software Grant - http://www.osjava.org/norbert/)
>
> Initial set of committers:
> ==========================
> Project Lead
> Michael Becke
>
> Project Committers
> Adrian Sutton
> Ortwin Glueck
> Oleg Kalnichevski
> Henri Yandell
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re: [Request for Comment] Http Components proposal
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, Oct 19, 2005 at 11:42:47PM -0400, Henri Yandell wrote:
>
> Oleg, did Robert's bits all get into the charter?
>
> Can I go ahead and call a vote?
>
> The usual apologies for my slowness in returning back to the thread. I
> need to kick myself into spending the next couple of days sending out
> Jakarta email on various threads.
>
> Hen
>
Hi Henri
There's nothing you need to apologize for. The work at Jakarta on top
our regular daily responsibilities is a tough balancing act for most of
us.
All Robert's bits made it into the charter draft
<http://wiki.apache.org/jakarta-httpclient/NewProjectCharter>. Please go
ahead and call a vote.
Cheers,
Oleg
> On Thu, 6 Oct 2005, Oleg Kalnichevski wrote:
>
> >On Thu, Oct 06, 2005 at 10:51:24AM +0100, robert burrell donkin wrote:
> >>just a few more from me:
> >>
> >>* Jakarta Http Components continues the development of Jakarta
> >>HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
> >>of HTTP components. This tool focuses strictly on the client side of
> >>HTTP.
> >>
> >>->
> >>
> >>* Jakarta Http Components continues the development of Jakarta
> >>HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
> >>of HTTP components. This tool focuses on the client side of HTTP.
> >>
> >>'strictly' is an unnecessary and subjective qualifier so probably best
> >>removed.
> >>
> >>* Jakarta Http Components MAY develop non-client components (such as an
> >>HTTP connector, a lightweight server component, proxy components) as
> >>reference material to demonstrate the capabilities of the toolset. The
> >>said artifacts ARE NOT meant for production use and are not released as
> >>official Apache Jakarta products.
> >>
> >>->
> >>
> >>* Jakarta Http Components MAY develop application layer components
> >>(such as an HTTP connector, a lightweight server component, proxy
> >>components) as reference material to demonstrate the capabilities of the
> >>toolset. The said artifacts ARE NOT meant for production use and are not
> >>released as official Apache Jakarta products.
> >>
> >>this fits in better with the rest of the draft: low level transport
> >>layer APIs suitable for use on servers may be developed but application
> >>layer components (whether client or server) may only be developed as
> >>demonstrations.
> >>
> >>i'd also like to add a new clause:
> >>
> >>* Jakarta Http Components is additional charged with the maintenance of
> >>the existing jakarta-commons httpclient component.
> >>
> >>this makes it clear that the sub-project can and will maintain the
> >>existing httpclient components even if they would not longer be
> >>considered in-scope.
> >>
> >>all just IMHO, of course
> >>
> >
> >Hi Robert,
> >
> >I believe the changes you have suggested are quite reasonable. Please do
> >not be shy and feel free to tweak the draft of the project charter directly
> >in the Wiki:
> >
> >http://wiki.apache.org/jakarta-httpclient/NewProjectCharter
> >
> >Cheers,
> >
> >Oleg
> >
> >
> >>- robert
> >>
> >>On Thu, 2005-10-06 at 01:10 -0400, Henri Yandell wrote:
> >>>Any more comments before I call a vote?
> >>>
> >>>Hen
> >>>
> >>>On Sat, 24 Sep 2005, Henri Yandell wrote:
> >>>
> >>>>
> >>>>Prior to calling a PMC vote here in a week or two, I'd like to ask if
> >>>>anybody
> >>>>has any comments on the following proposal for Commons HttpClient to
> >>>>become a
> >>>>Jakarta subproject focusing on Http components.
> >>>>
> >>>>Hen
> >>>>
> >>>>*********************************************************************
> >>>>
> >>>>(The following charter for Jakarta Http Components project is pending
> >>>>approval of the Jakarta Project Management Committee (PMC). )
> >>>>
> >>>>Rationale:
> >>>>=========
> >>>>
> >>>>The original Jakarta Commons HttpClient API has a number limitations
> >>>>that
> >>>>cannot be resolved without a significant architectural redesign.
> >>>>Moreover,
> >>>>Jakarta Commons HttpClient has been increasingly used in applications
> >>>>and
> >>>>environments it has not been specifically designed for. The existing
> >>>>monolithic design no longer adequately reflects the use patterns of
> >>>>HttpClient.
> >>>>
> >>>>HttpClient needs to be refactored into a toolset of simple, low level
> >>>>HTTP
> >>>>components suitable for building more specialized HTTP services.
> >>>>
> >>>>Project scope:
> >>>>=============
> >>>>
> >>>>* Jakarta Http Components develops a toolset of low level components
> >>>>focused exclusively at the transport aspects of HTTP protocol.
> >>>>
> >>>>* Jakarta Http Components MUST be content agnostic. The project DOES NOT
> >>>>develop components intended to produce or consume content of HTTP
> >>>>messages.
> >>>>
> >>>>* Jakarta Http Components continues the development of Jakarta
> >>>>HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
> >>>>HTTP components. This tool focuses strictly on the client side of HTTP.
> >>>>
> >>>>* Jakarta Http Components MAY develop non-client components (such as an
> >>>>HTTP connector, a lightweight server component, proxy components) as
> >>>>reference material to demonstrate the capabilities of the toolset. The
> >>>>said artifacts ARE NOT meant for production use and are not released as
> >>>>official Apache Jakarta products.
> >>>>
> >>>>* Jakarta Http Components collaborates with other projects to develop
> >>>>specialized HTTP services for production use based on the toolset of
> >>>>HTTP
> >>>>components.
> >>>>
> >>>>* Jakarta Http Components DOES NOT define a server side API on top of
> >>>>the low
> >>>>level transport API.
> >>>>
> >>>>Targeted specifications and standards:
> >>>>=====================================
> >>>>* RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
> >>>>* RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
> >>>>* RFC2617 HTTP Authentication: Basic and Digest Access Authentication
> >>>>* RFC2109 HTTP State Management Mechanism -- Cookies
> >>>>* RFC2965 HTTP State Management Mechanism -- Cookie2
> >>>>* A standard for robot exclusion - robots.txt parser (contribution
> >>>>requiring
> >>>>Software Grant - http://www.osjava.org/norbert/)
> >>>>
> >>>>Initial set of committers:
> >>>>==========================
> >>>>Project Lead
> >>>> Michael Becke
> >>>>
> >>>>Project Committers
> >>>> Adrian Sutton
> >>>> Ortwin Glueck
> >>>> Oleg Kalnichevski
> >>>> Henri Yandell
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: general-help@jakarta.apache.org
> >>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: general-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: general-help@jakarta.apache.org
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Henri Yandell <ba...@generationjava.com>.
Oleg, did Robert's bits all get into the charter?
Can I go ahead and call a vote?
The usual apologies for my slowness in returning back to the thread. I
need to kick myself into spending the next couple of days sending out
Jakarta email on various threads.
Hen
On Thu, 6 Oct 2005, Oleg Kalnichevski wrote:
> On Thu, Oct 06, 2005 at 10:51:24AM +0100, robert burrell donkin wrote:
>> just a few more from me:
>>
>> * Jakarta Http Components continues the development of Jakarta
>> HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
>> of HTTP components. This tool focuses strictly on the client side of
>> HTTP.
>>
>> ->
>>
>> * Jakarta Http Components continues the development of Jakarta
>> HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
>> of HTTP components. This tool focuses on the client side of HTTP.
>>
>> 'strictly' is an unnecessary and subjective qualifier so probably best
>> removed.
>>
>> * Jakarta Http Components MAY develop non-client components (such as an
>> HTTP connector, a lightweight server component, proxy components) as
>> reference material to demonstrate the capabilities of the toolset. The
>> said artifacts ARE NOT meant for production use and are not released as
>> official Apache Jakarta products.
>>
>> ->
>>
>> * Jakarta Http Components MAY develop application layer components
>> (such as an HTTP connector, a lightweight server component, proxy
>> components) as reference material to demonstrate the capabilities of the
>> toolset. The said artifacts ARE NOT meant for production use and are not
>> released as official Apache Jakarta products.
>>
>> this fits in better with the rest of the draft: low level transport
>> layer APIs suitable for use on servers may be developed but application
>> layer components (whether client or server) may only be developed as
>> demonstrations.
>>
>> i'd also like to add a new clause:
>>
>> * Jakarta Http Components is additional charged with the maintenance of
>> the existing jakarta-commons httpclient component.
>>
>> this makes it clear that the sub-project can and will maintain the
>> existing httpclient components even if they would not longer be
>> considered in-scope.
>>
>> all just IMHO, of course
>>
>
> Hi Robert,
>
> I believe the changes you have suggested are quite reasonable. Please do
> not be shy and feel free to tweak the draft of the project charter directly
> in the Wiki:
>
> http://wiki.apache.org/jakarta-httpclient/NewProjectCharter
>
> Cheers,
>
> Oleg
>
>
>> - robert
>>
>> On Thu, 2005-10-06 at 01:10 -0400, Henri Yandell wrote:
>>> Any more comments before I call a vote?
>>>
>>> Hen
>>>
>>> On Sat, 24 Sep 2005, Henri Yandell wrote:
>>>
>>>>
>>>> Prior to calling a PMC vote here in a week or two, I'd like to ask if anybody
>>>> has any comments on the following proposal for Commons HttpClient to become a
>>>> Jakarta subproject focusing on Http components.
>>>>
>>>> Hen
>>>>
>>>> *********************************************************************
>>>>
>>>> (The following charter for Jakarta Http Components project is pending
>>>> approval of the Jakarta Project Management Committee (PMC). )
>>>>
>>>> Rationale:
>>>> =========
>>>>
>>>> The original Jakarta Commons HttpClient API has a number limitations that
>>>> cannot be resolved without a significant architectural redesign. Moreover,
>>>> Jakarta Commons HttpClient has been increasingly used in applications and
>>>> environments it has not been specifically designed for. The existing
>>>> monolithic design no longer adequately reflects the use patterns of
>>>> HttpClient.
>>>>
>>>> HttpClient needs to be refactored into a toolset of simple, low level HTTP
>>>> components suitable for building more specialized HTTP services.
>>>>
>>>> Project scope:
>>>> =============
>>>>
>>>> * Jakarta Http Components develops a toolset of low level components
>>>> focused exclusively at the transport aspects of HTTP protocol.
>>>>
>>>> * Jakarta Http Components MUST be content agnostic. The project DOES NOT
>>>> develop components intended to produce or consume content of HTTP
>>>> messages.
>>>>
>>>> * Jakarta Http Components continues the development of Jakarta
>>>> HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
>>>> HTTP components. This tool focuses strictly on the client side of HTTP.
>>>>
>>>> * Jakarta Http Components MAY develop non-client components (such as an
>>>> HTTP connector, a lightweight server component, proxy components) as
>>>> reference material to demonstrate the capabilities of the toolset. The
>>>> said artifacts ARE NOT meant for production use and are not released as
>>>> official Apache Jakarta products.
>>>>
>>>> * Jakarta Http Components collaborates with other projects to develop
>>>> specialized HTTP services for production use based on the toolset of HTTP
>>>> components.
>>>>
>>>> * Jakarta Http Components DOES NOT define a server side API on top of the low
>>>> level transport API.
>>>>
>>>> Targeted specifications and standards:
>>>> =====================================
>>>> * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
>>>> * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
>>>> * RFC2617 HTTP Authentication: Basic and Digest Access Authentication
>>>> * RFC2109 HTTP State Management Mechanism -- Cookies
>>>> * RFC2965 HTTP State Management Mechanism -- Cookie2
>>>> * A standard for robot exclusion - robots.txt parser (contribution requiring
>>>> Software Grant - http://www.osjava.org/norbert/)
>>>>
>>>> Initial set of committers:
>>>> ==========================
>>>> Project Lead
>>>> Michael Becke
>>>>
>>>> Project Committers
>>>> Adrian Sutton
>>>> Ortwin Glueck
>>>> Oleg Kalnichevski
>>>> Henri Yandell
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: general-help@jakarta.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: general-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, Oct 06, 2005 at 10:51:24AM +0100, robert burrell donkin wrote:
> just a few more from me:
>
> * Jakarta Http Components continues the development of Jakarta
> HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
> of HTTP components. This tool focuses strictly on the client side of
> HTTP.
>
> ->
>
> * Jakarta Http Components continues the development of Jakarta
> HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
> of HTTP components. This tool focuses on the client side of HTTP.
>
> 'strictly' is an unnecessary and subjective qualifier so probably best
> removed.
>
> * Jakarta Http Components MAY develop non-client components (such as an
> HTTP connector, a lightweight server component, proxy components) as
> reference material to demonstrate the capabilities of the toolset. The
> said artifacts ARE NOT meant for production use and are not released as
> official Apache Jakarta products.
>
> ->
>
> * Jakarta Http Components MAY develop application layer components
> (such as an HTTP connector, a lightweight server component, proxy
> components) as reference material to demonstrate the capabilities of the
> toolset. The said artifacts ARE NOT meant for production use and are not
> released as official Apache Jakarta products.
>
> this fits in better with the rest of the draft: low level transport
> layer APIs suitable for use on servers may be developed but application
> layer components (whether client or server) may only be developed as
> demonstrations.
>
> i'd also like to add a new clause:
>
> * Jakarta Http Components is additional charged with the maintenance of
> the existing jakarta-commons httpclient component.
>
> this makes it clear that the sub-project can and will maintain the
> existing httpclient components even if they would not longer be
> considered in-scope.
>
> all just IMHO, of course
>
Hi Robert,
I believe the changes you have suggested are quite reasonable. Please do
not be shy and feel free to tweak the draft of the project charter directly
in the Wiki:
http://wiki.apache.org/jakarta-httpclient/NewProjectCharter
Cheers,
Oleg
> - robert
>
> On Thu, 2005-10-06 at 01:10 -0400, Henri Yandell wrote:
> > Any more comments before I call a vote?
> >
> > Hen
> >
> > On Sat, 24 Sep 2005, Henri Yandell wrote:
> >
> > >
> > > Prior to calling a PMC vote here in a week or two, I'd like to ask if anybody
> > > has any comments on the following proposal for Commons HttpClient to become a
> > > Jakarta subproject focusing on Http components.
> > >
> > > Hen
> > >
> > > *********************************************************************
> > >
> > > (The following charter for Jakarta Http Components project is pending
> > > approval of the Jakarta Project Management Committee (PMC). )
> > >
> > > Rationale:
> > > =========
> > >
> > > The original Jakarta Commons HttpClient API has a number limitations that
> > > cannot be resolved without a significant architectural redesign. Moreover,
> > > Jakarta Commons HttpClient has been increasingly used in applications and
> > > environments it has not been specifically designed for. The existing
> > > monolithic design no longer adequately reflects the use patterns of
> > > HttpClient.
> > >
> > > HttpClient needs to be refactored into a toolset of simple, low level HTTP
> > > components suitable for building more specialized HTTP services.
> > >
> > > Project scope:
> > > =============
> > >
> > > * Jakarta Http Components develops a toolset of low level components
> > > focused exclusively at the transport aspects of HTTP protocol.
> > >
> > > * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> > > develop components intended to produce or consume content of HTTP
> > > messages.
> > >
> > > * Jakarta Http Components continues the development of Jakarta
> > > HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
> > > HTTP components. This tool focuses strictly on the client side of HTTP.
> > >
> > > * Jakarta Http Components MAY develop non-client components (such as an
> > > HTTP connector, a lightweight server component, proxy components) as
> > > reference material to demonstrate the capabilities of the toolset. The
> > > said artifacts ARE NOT meant for production use and are not released as
> > > official Apache Jakarta products.
> > >
> > > * Jakarta Http Components collaborates with other projects to develop
> > > specialized HTTP services for production use based on the toolset of HTTP
> > > components.
> > >
> > > * Jakarta Http Components DOES NOT define a server side API on top of the low
> > > level transport API.
> > >
> > > Targeted specifications and standards:
> > > =====================================
> > > * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
> > > * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
> > > * RFC2617 HTTP Authentication: Basic and Digest Access Authentication
> > > * RFC2109 HTTP State Management Mechanism -- Cookies
> > > * RFC2965 HTTP State Management Mechanism -- Cookie2
> > > * A standard for robot exclusion - robots.txt parser (contribution requiring
> > > Software Grant - http://www.osjava.org/norbert/)
> > >
> > > Initial set of committers:
> > > ==========================
> > > Project Lead
> > > Michael Becke
> > >
> > > Project Committers
> > > Adrian Sutton
> > > Ortwin Glueck
> > > Oleg Kalnichevski
> > > Henri Yandell
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
just a few more from me:
* Jakarta Http Components continues the development of Jakarta
HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
of HTTP components. This tool focuses strictly on the client side of
HTTP.
->
* Jakarta Http Components continues the development of Jakarta
HttpClient (formerly Jakarta Commons HttpClient ) based on the toolset
of HTTP components. This tool focuses on the client side of HTTP.
'strictly' is an unnecessary and subjective qualifier so probably best
removed.
* Jakarta Http Components MAY develop non-client components (such as an
HTTP connector, a lightweight server component, proxy components) as
reference material to demonstrate the capabilities of the toolset. The
said artifacts ARE NOT meant for production use and are not released as
official Apache Jakarta products.
->
* Jakarta Http Components MAY develop application layer components
(such as an HTTP connector, a lightweight server component, proxy
components) as reference material to demonstrate the capabilities of the
toolset. The said artifacts ARE NOT meant for production use and are not
released as official Apache Jakarta products.
this fits in better with the rest of the draft: low level transport
layer APIs suitable for use on servers may be developed but application
layer components (whether client or server) may only be developed as
demonstrations.
i'd also like to add a new clause:
* Jakarta Http Components is additional charged with the maintenance of
the existing jakarta-commons httpclient component.
this makes it clear that the sub-project can and will maintain the
existing httpclient components even if they would not longer be
considered in-scope.
all just IMHO, of course
- robert
On Thu, 2005-10-06 at 01:10 -0400, Henri Yandell wrote:
> Any more comments before I call a vote?
>
> Hen
>
> On Sat, 24 Sep 2005, Henri Yandell wrote:
>
> >
> > Prior to calling a PMC vote here in a week or two, I'd like to ask if anybody
> > has any comments on the following proposal for Commons HttpClient to become a
> > Jakarta subproject focusing on Http components.
> >
> > Hen
> >
> > *********************************************************************
> >
> > (The following charter for Jakarta Http Components project is pending
> > approval of the Jakarta Project Management Committee (PMC). )
> >
> > Rationale:
> > =========
> >
> > The original Jakarta Commons HttpClient API has a number limitations that
> > cannot be resolved without a significant architectural redesign. Moreover,
> > Jakarta Commons HttpClient has been increasingly used in applications and
> > environments it has not been specifically designed for. The existing
> > monolithic design no longer adequately reflects the use patterns of
> > HttpClient.
> >
> > HttpClient needs to be refactored into a toolset of simple, low level HTTP
> > components suitable for building more specialized HTTP services.
> >
> > Project scope:
> > =============
> >
> > * Jakarta Http Components develops a toolset of low level components
> > focused exclusively at the transport aspects of HTTP protocol.
> >
> > * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> > develop components intended to produce or consume content of HTTP
> > messages.
> >
> > * Jakarta Http Components continues the development of Jakarta
> > HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
> > HTTP components. This tool focuses strictly on the client side of HTTP.
> >
> > * Jakarta Http Components MAY develop non-client components (such as an
> > HTTP connector, a lightweight server component, proxy components) as
> > reference material to demonstrate the capabilities of the toolset. The
> > said artifacts ARE NOT meant for production use and are not released as
> > official Apache Jakarta products.
> >
> > * Jakarta Http Components collaborates with other projects to develop
> > specialized HTTP services for production use based on the toolset of HTTP
> > components.
> >
> > * Jakarta Http Components DOES NOT define a server side API on top of the low
> > level transport API.
> >
> > Targeted specifications and standards:
> > =====================================
> > * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
> > * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
> > * RFC2617 HTTP Authentication: Basic and Digest Access Authentication
> > * RFC2109 HTTP State Management Mechanism -- Cookies
> > * RFC2965 HTTP State Management Mechanism -- Cookie2
> > * A standard for robot exclusion - robots.txt parser (contribution requiring
> > Software Grant - http://www.osjava.org/norbert/)
> >
> > Initial set of committers:
> > ==========================
> > Project Lead
> > Michael Becke
> >
> > Project Committers
> > Adrian Sutton
> > Ortwin Glueck
> > Oleg Kalnichevski
> > Henri Yandell
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Request for Comment] Http Components proposal
Posted by Henri Yandell <ba...@generationjava.com>.
Any more comments before I call a vote?
Hen
On Sat, 24 Sep 2005, Henri Yandell wrote:
>
> Prior to calling a PMC vote here in a week or two, I'd like to ask if anybody
> has any comments on the following proposal for Commons HttpClient to become a
> Jakarta subproject focusing on Http components.
>
> Hen
>
> *********************************************************************
>
> (The following charter for Jakarta Http Components project is pending
> approval of the Jakarta Project Management Committee (PMC). )
>
> Rationale:
> =========
>
> The original Jakarta Commons HttpClient API has a number limitations that
> cannot be resolved without a significant architectural redesign. Moreover,
> Jakarta Commons HttpClient has been increasingly used in applications and
> environments it has not been specifically designed for. The existing
> monolithic design no longer adequately reflects the use patterns of
> HttpClient.
>
> HttpClient needs to be refactored into a toolset of simple, low level HTTP
> components suitable for building more specialized HTTP services.
>
> Project scope:
> =============
>
> * Jakarta Http Components develops a toolset of low level components
> focused exclusively at the transport aspects of HTTP protocol.
>
> * Jakarta Http Components MUST be content agnostic. The project DOES NOT
> develop components intended to produce or consume content of HTTP
> messages.
>
> * Jakarta Http Components continues the development of Jakarta
> HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
> HTTP components. This tool focuses strictly on the client side of HTTP.
>
> * Jakarta Http Components MAY develop non-client components (such as an
> HTTP connector, a lightweight server component, proxy components) as
> reference material to demonstrate the capabilities of the toolset. The
> said artifacts ARE NOT meant for production use and are not released as
> official Apache Jakarta products.
>
> * Jakarta Http Components collaborates with other projects to develop
> specialized HTTP services for production use based on the toolset of HTTP
> components.
>
> * Jakarta Http Components DOES NOT define a server side API on top of the low
> level transport API.
>
> Targeted specifications and standards:
> =====================================
> * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
> * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
> * RFC2617 HTTP Authentication: Basic and Digest Access Authentication
> * RFC2109 HTTP State Management Mechanism -- Cookies
> * RFC2965 HTTP State Management Mechanism -- Cookie2
> * A standard for robot exclusion - robots.txt parser (contribution requiring
> Software Grant - http://www.osjava.org/norbert/)
>
> Initial set of committers:
> ==========================
> Project Lead
> Michael Becke
>
> Project Committers
> Adrian Sutton
> Ortwin Glueck
> Oleg Kalnichevski
> Henri Yandell
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org