On Tue, 2006-09-19 at 16:12 +0200, Roland Weber wrote: > Hi Oleg, > > I've had some time to relax and think about connections. > As a result, I would like to sum up what I think you are > trying to achieve. Please have a look through it and > correct me where I got you wrong... > > In HttpClient, the Connection class directly implemented > all the functionality that was needed. In HttpCore, the > HttpClientConnection interface started out in a similar > fashion, providing basically all the methods we expected > an application or any component to be interested in. > If I got your intentions right this time, you are trying > to change that. Instead of a full-blown abstraction for > client connections, you want HttpCore to define a kind of > adapter interface, which holds only those methods that > are required within HttpCore. Defining a full-blown > abstraction is left to HttpConn. > > The responsibility for opening a connection should be moved > outside of HttpCore. Hence, the interface does not need to > specify an open(...) method. HttpCore does not care where > the connection points to, hence the interface does not need > a getTargetHost() method. SocketFactory is only needed to > open a connection, hence it is not needed in HttpCore. >
Precisely. I am trying to keep HttpCore as a minimalistic, transport agnostic protocol layer, that is usable with classic I/O sockets, NIO channels, abstract I/O transports such as MINA and what not. The job of HttpCore should be in my opinion to ensure RFC 2616 compliant serialization and deserialization of HTTP messages. > Have you considered ConnectionReuseStrategy? If opening > connections is not the responsibility of HttpCore, then > deciding on reuse vs. opening a new one shouldn't be either. > ConnectionReuseStrategy is not really needed for the client side. It is a must for the server side HttpService, though. It is used on the server side to determine whether a connection can be used for subsequent requests or it should be dropped in order to delimiter the response content. 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]
