Re: [Request for Comment] Http Components proposal
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
Re: [Request for Comment] Http Components proposal
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
Re: [Request for Comment] Http Components proposal
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Request for Comment] Http Components proposal
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Request for Comment] Http Components proposal
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Request for Comment] Http Components proposal
On Sat, 2005-09-24 at 20:34 -0700, Martin Cooper wrote: On 9/24/05, Henri Yandell [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Request for Comment] Http Components proposal
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Request for Comment] Http Components proposal
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Request for Comment] Http Components proposal
On 9/24/05, Henri Yandell [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
