hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [Jakarta-httpclient Wiki] Update of "NewProjectCharter" by MichaelBecke
Date Wed, 14 Sep 2005 08:48:16 GMT
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


Mime
View raw message