You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Apache Wiki <wi...@apache.org> on 2005/09/14 04:50:21 UTC
[Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by MichaelBecke:
http://wiki.apache.org/jakarta-httpclient/NewProjectCharter
The comment on the change is:
Small wording changes
------------------------------------------------------------------------------
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 }}} project develops a toolset of low level components focused exclusively at the transport aspects of HTTP protocol
+ * {{{ Jakarta Http Components }}} develops a toolset of low level components focused exclusively at the transport aspects of HTTP protocol.
- * {{{ Jakarta Http Components }}} project '''DOES NOT''' define an application API on top of the low level transport API
- * {{{ 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 }}} '''MUST''' be content agnostic. The project '''DOES NOT''' develop components intended to produce or consume content of HTTP messages.
- * {{{ Jakarta Http Components }}} project continues the development of {{{ Jakarta HttpClient }}} (former {{{ Jakarta Commons HttpClient }}}) based on the toolset of HTTP components
+ * {{{ 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 }}} project develops an HTTP connector or a lightweight server component as a 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 }}} develops an HTTP connector or a lightweight server component as a 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 }}} project collaborates with other projects to develop specialized HTTP services for production use based on the toolset of HTTP components
+ * {{{ 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
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Posted by Michael Becke <mb...@gmail.com>.
Works for me. The new wording sounds good.
Mike
On 9/14/05, Ortwin Glück <od...@odi.ch> wrote:
>
>
> Oleg Kalnichevski wrote:
> > Fair enough. As far as test (non-releasable) components go we are free
> > to do what we please. Go ahead and add lightweight proxy to the list of
> > reference materials
> >
>
> ok
>
> > Actually I think the simple proxy does not buffer stuff [1]. It is
> > rather flaky, however, and needs significantly more work.
>
> True. Sorry for spreading bad rumors. This proxy implementation is not
> so bad, actually!
>
> --
> [web] http://www.odi.ch/
> [blog] http://www.odi.ch/weblog/
> [pgp] key 0x81CF3416
> finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> Fair enough. As far as test (non-releasable) components go we are free
> to do what we please. Go ahead and add lightweight proxy to the list of
> reference materials
>
ok
> Actually I think the simple proxy does not buffer stuff [1]. It is
> rather flaky, however, and needs significantly more work.
True. Sorry for spreading bad rumors. This proxy implementation is not
so bad, actually!
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, Sep 14, 2005 at 10:31:06AM +0200, Ortwin Gl?ck wrote:
>
>
> Oleg Kalnichevski wrote:
> >MIME is a transfer encoding not a content encoding (at least imo). So,
> >we would still be allowed to develop multipart components. This said, I
> >would rather prefer to migrate multipart related code to Commons Codec.
> >There's already multipart-codec project in the Commons Sandbox
>
> I'd like to see Multipart-MIME outside HttpClient project as well. As an
> optional dependency.
>
> >
> >
> >>>+ * {{{ Jakarta Http Components }}} develops an HTTP connector or a
> >>>lightweight server component as a 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.
> >>
> >>I would rephrase this so it is logically "not client" instead of
> >>"server" component. This would allow us also to create a proxy
> >>implementation (which we will need for testing purposes anyway).
> >>
> >
> >
> >A full-fledged HTTP/1.1 compliant caching proxy or reverse proxy would
> >be a major undertaking and should be developed as a separate project.
> >Let us keep it out of scope for the time being. We simply have no
> >resources for such a massive effort.
> >
> >Oleg
>
> I know that this is complex, Oleg. And I know that there are projects
> (Built-in cache in Magnolia for instance) that were trying to do it and
> have failed miserably. And I would never go down the road to build a
> fully fledged proxy. But we actually have a simple (i.e. not fully
> compliant) implementation already. This has two benefits:
> * we can use it for our test suite and simulate any (odd) proxy behaviour
> * we ensure that the components we build are useful for building a
> proxy (same argument as for server code)
>
Fair enough. As far as test (non-releasable) components go we are free
to do what we please. Go ahead and add lightweight proxy to the list of
reference materials
> The problem with our current proxy code is that it needs to buffer the
> content completely. It is currently impossible to write a non-buffering
> proxy.
>
Actually I think the simple proxy does not buffer stuff [1]. It is
rather flaky, however, and needs significantly more work.
Oleg
[1]
http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/src/test/org/apache/commons/httpclient/server/TransparentProxyRequestHandler.java
> Odi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> MIME is a transfer encoding not a content encoding (at least imo). So,
> we would still be allowed to develop multipart components. This said, I
> would rather prefer to migrate multipart related code to Commons Codec.
> There's already multipart-codec project in the Commons Sandbox
I'd like to see Multipart-MIME outside HttpClient project as well. As an
optional dependency.
>
>
>>>+ * {{{ Jakarta Http Components }}} develops an HTTP connector or a
>>>lightweight server component as a 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.
>>
>>I would rephrase this so it is logically "not client" instead of
>>"server" component. This would allow us also to create a proxy
>>implementation (which we will need for testing purposes anyway).
>>
>
>
> A full-fledged HTTP/1.1 compliant caching proxy or reverse proxy would
> be a major undertaking and should be developed as a separate project.
> Let us keep it out of scope for the time being. We simply have no
> resources for such a massive effort.
>
> Oleg
I know that this is complex, Oleg. And I know that there are projects
(Built-in cache in Magnolia for instance) that were trying to do it and
have failed miserably. And I would never go down the road to build a
fully fledged proxy. But we actually have a simple (i.e. not fully
compliant) implementation already. This has two benefits:
* we can use it for our test suite and simulate any (odd) proxy behaviour
* we ensure that the components we build are useful for building a
proxy (same argument as for server code)
The problem with our current proxy code is that it needs to buffer the
content completely. It is currently impossible to write a non-buffering
proxy.
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, Sep 14, 2005 at 09:36:33AM +0200, Ortwin Gl?ck wrote:
>
>
> Apache Wiki wrote:
> >+ * {{{ Jakarta Http Components }}} '''MUST''' be content agnostic.
> >The project '''DOES NOT''' develop components intended to produce or
> >consume content of HTTP messages.
>
> I guess Multipart-MIME is considered transport level.
>
MIME is a transfer encoding not a content encoding (at least imo). So,
we would still be allowed to develop multipart components. This said, I
would rather prefer to migrate multipart related code to Commons Codec.
There's already multipart-codec project in the Commons Sandbox
> >+ * {{{ Jakarta Http Components }}} develops an HTTP connector or a
> >lightweight server component as a 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.
>
> I would rephrase this so it is logically "not client" instead of
> "server" component. This would allow us also to create a proxy
> implementation (which we will need for testing purposes anyway).
>
A full-fledged HTTP/1.1 compliant caching proxy or reverse proxy would
be a major undertaking and should be developed as a separate project.
Let us keep it out of scope for the time being. We simply have no
resources for such a massive effort.
Oleg
>
> --
> [web] http://www.odi.ch/
> [blog] http://www.odi.ch/weblog/
> [pgp] key 0x81CF3416
> finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Posted by Ortwin Glück <od...@odi.ch>.
Apache Wiki wrote:
> + * {{{ Jakarta Http Components }}} '''MUST''' be content agnostic.
> The project '''DOES NOT''' develop components intended to produce or
> consume content of HTTP messages.
I guess Multipart-MIME is considered transport level.
> + * {{{ Jakarta Http Components }}} develops an HTTP connector or a
> lightweight server component as a 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.
I would rephrase this so it is logically "not client" instead of
"server" component. This would allow us also to create a proxy
implementation (which we will need for testing purposes anyway).
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org