On Sun, Dec 11, 2005 at 10:25:34PM +0100, Oleg Kalnichevski wrote:
> On Sun, 2005-12-11 at 15:24 +0100, Roland Weber wrote:
<snip/>
> >
> > public interface HttpClientConnection {
> >
> > public void sendRequest(HttpRequest req, HttpParams params)
> >
> > public void sendEntity(HttpEntity entity, HttpParams params)
> >
> > public HttpResponse receiveResponse(HttpParams params)
> >
> > public HttpEntity receiveEntity(HttpParams params)
> >
> > } // interface HttpClientConnection
> >
> >
>
> I think the idea to decouple request and entity processing logic as a
> remedy for the problems identified above is a reasonable one. However, I
> am not entirely sure it solves all the problems. At some point you will
> have to assemble the complete HTTP response by combining the entity to
> the header. However, since HttpResponse represents an immutable message
> this will not be possible, unless you cast HttpResponse to
> HttpMutableResponse, thus completely defeating the whole idea of
> separating those two interfaces in the first place.
>
> Les us try to redesign the HttpClientConnection interface, however, I do
> suspect strongly the only clean solution to the problem may be having
> different interfaces representing different types of connections: a
> regular client connection, a proxy-side connection and a client
> connection capable of pipelining requests at the expense of not
> supporting 1xx status codes. I am afraid we may fail to come up with a
> reasonably clean interface capable of representing all different types
> of connections.
>
> Oleg
>
> >
> > Passing 'params' to sendRequest() is not necessary since params are
> > available from HttpRequest, but it is more consistent with the
> > receive methods that need the params argument. sendRequest() sends
> > only the request line, headers, and empty line, but no entity.
> > sendEntity() could take an HttpEntityEnclosingRequest instead of the
> > entity itself as an argument, though it shouldn't need anything but
> > the entity and params.
> > receiveResponse() receives only the status line and request headers.
> > It doesn't need the request anymore, since it doesn't have to decide
> > whether the response includes an entity. It returns all responses,
> > including those with 1xx status codes. receiveEntity() could take
> > an EntityGenerator as an argument, in that case sendEntity() should
> > be changed to take an EntityWriter for the sake of symmetry.
> > I have not dug deeper into the code, so I don't know how the data
> > transmitter below the connection is affected by these suggestions.
> >
> >
> > I'll be on a business trip for a few days, but I'm looking forward
> > to reading your comments and responding when I'm back.
> >
> > cheers,
> > Roland
Roland,
I thought the whole problem over a little more. The idea to factor out 1xx
handling logic from the low level connection class does make a lot of sense
conceptually. However, I do not think that the new interface makes a better
public API than the existing one
I suggest we factor out the common client connection code into an abstract
impl class. The class will be state-less and will have no special knowledge
of the 1xx status codes. The class will have a similar method signature to
that you have proposed.
class org.apache.http.impl.AbstractSendingHttpConnection extends
org.apache.http.impl.AbstractHttpConnection {
protected void sendRequestHeader(HttpRequest req);
protected void sendRequestEntity(HttpEntityEnclosingRequest req)
protected HttpMutableResponse receiveResponseHeader(HttpParams params);
protected HttpMutableEntity sendRequestEntity(HttpParams params);
}
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;
}
The DefaultHttpClientConnection subclasses the new
AbstractSendingHttpConnection class and is made the 'expect: continue'
handshake aware. The control logic can be implemented internally (this
will require the class to maintain the state rendering it stateful and
threading-unsafe) or externally in the RequestExecutor (this will
render the class modal. The RequestExecutor will have to know the mode
(the sequence of method calls) required to produce the desired effect)
public class DefaultHttpClientConnection implements HttpClientConnection
extends AbstractSendingHttpConnection {
}
The DefaultAsyncHttpClientConnection subclasses the new
AbstractSendingHttpConnection class and is made capable of 'pipelining'
requests at the expense of not supporting the 1xx based control logic
public class DefaultAsyncHttpClientConnection implements HttpClientConnection
extends AbstractSendingHttpConnection {
}
Can you live with that?
Oleg
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
