On Wed, Dec 14, 2005 at 09:50:01PM +0100, Roland Weber wrote:
> Hi Oleg,
>
Hi Roland
See my comments in-line
>
> The general idea I have in mind is to isolate all knowledge about a
> sequence of request/reply/entity particles behind a single interface,
> which can be used for both synchronous and asynchronous operation.
> Here "knowledge about sequences" includes:
> - expect/continue handshake
> - redirect handling
> - authentication handling
> - ... (in case I forgot something :-)
I think this is essentially where we tend to differ. I believe that 1xx
status codes serve a different purpose compared to 3xx and 4xx and
therefore should be handled differently.
> It's a very long way to go, but we could then have different
> implementations of that interface for interactive user agents,
> proxies, non-interactive robots or spiders, and so on. That's
> why I would like to move the expect/continue handshake completely
> out of the connection itself.
Fine by me. I like this idea. However I personally find the interface
you have proposed too much of a price to be paid. What I dislike about
it is that it exposes mutable objects to the caller and leave it up to
the caller to assemble various bits and pieces into a consistent HTTP
message. I would very much prefer for all Http*Connection interfaces to
always consume and produce _consistent_ _immutable_ HTTP messages
leaving all the low level details to non-public impl classes
>
> > The HttpClientConnection interface no longer has any notion of a special
> > control logic such as the 'expect: continue' handshake. Just plain-vanilla
> > send a request, get a response stuff
> >
> > public interface HttpClientConnection extends HttpConnection {
> >
> > ...
> >
> > void sendRequest(HttpRequest request) throws HttpException, IOException;
> >
> > HttpResponse receiveResponse() throws HttpException, IOException;
> >
> > }
>
> This will not allow the control logic to be implemented outside of the
> connection interface. The control logic for expect/continue, if implemented
> outside of the connection, has to indicate "send the request header" versus
> "send the request entity". Your suggestion would require a specialized
> interface for this, or some hack like passing a flag in the parameters
> that are associated with the request. That's not really an improvement
> over the current situation.
Let me try to hack something up. I have a few ideas to try
>
> I guess our different lines of thought are due to the fact that the new API
> does not yet have a "sequencer" object like the method director. I would
> like to introduce one now for supporting expect/continue (to be extended for
> other uses later), while you would like to offer expect/continue without an
> additional abstraction layer and a new interface that has to be instantiated,
> right?
>
> How about this:
> - make the HttpClientConnection generic (following my initial proposal,
> but with MutableHttpRequest and MutableHttpEntity)
> - provide a static helper to handle the expect/continue handshake, which
> provides an interface similar to the current HttpClientConnection
>
>
See my objections / reservations described above
>
> Let me know what you think. I have a hunch we'll need some more
> iterations to come up with a sound concept.
>
I suggest we tackle the problem step by step in a series of incremental
patches. This approach worked well for us in the past when we had some
disagreements regarding the 3.0 API
I'll start working on a patch that will factor the existing control
logic out of the DefaultHttpClientConnection class. Once that is done we
can discuss various options how to change the public
HttpClientConnection.
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> 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]
