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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
