On Fri, 2007-01-05 at 20:17 +0100, Roland Weber wrote: > Hi all, > > I've spent some time on reworking interfaces for HttpConn. > While the work is far from completed, some of the interfaces > are ready for review. As usual, I've spent more time than > I had planned, so I need to declare a break here in order to > take care of some other stuff for a while. I'll just give > you a summary of the changes and an outlook. >
Hi Roland I took the first (and rather cursory) look at the changes in HttpConn. Here is my feedback so far. More to come at a later point. I like you have done so far and I think it is a good start. Now onto the details. My gripes are rather minor and mostly related to class / method naming. > === Changes === > > I didn't touch the old code moved over from HttpClient 3.x. > We have two new interfaces, with default implementations: > > - org.apache.http.conn.UnmanagedClientConnection > A connection with the methods needed to open and tunnel. > It does not provide the data needed by a connection manager, > so it can not replace the old HttpHostConnection. > (1) I actually think ManagedClientConnection would be a better name for the interface, because it reflects the fact that the connection is not self-containing and requires an external entity to manage its state. (2) Can we do without #prepare(Socket) method? Do we really need it? What is the point of giving the connection an unconnected socket? > - org.apache.http.conn.SocketConnectionOperator > Encapsulates the knowledge about using SocketFactory > and SecureSocketFactory in order to open or update an > UnmanagedClientConnection. It does not know about > tunnelling. > This interface is meant to be thread safe. We could > also change the name to include a "Client" somewhere. > Since HttpConn is currently part of HttpClient, I > forgot that when I chose the name. How about ClientConnectionOperaton? > - Two examples show how to use the SocketConnectionOperator. > I learned quite a bit about tunnelling TLS/SSL connections > through proxies when coding the second example :-) > > === Outlook === > > a) Extended connection interface. > We do need another connection interface that provides > additional methods for connection management. The name I > have in mind is "ClientConnection", that's why the default > implementation of UnmanagedClientConnection is already > called DefaultClientConnection. > I have had some ideas, and some more ideas, and yet other > ideas about this interface. In the end, they are pointless. > I can't develop the interface without rewriting the connection > manager to see what is actually needed. That's a major effort, > and I can't tell yet when I will have the time. > We need something that works _now_, something we can run the existing test cases against, before we get carried too far away with all sorts of fancy ideas. I feel very strongly that at this point of time having something that works should take precedence over API clarity. Let us just merge the functionality of the HttpHostConnection into the UnmanagedClientConnection, mark it 'to be reviewed', and keep changes to the existing connection managers to the minimum. > b) Encapsulate tunnelling logic. > The SocketConnectionOperator does only half of the job > when opening a secure connection through a proxy. It is > missing the tunnelling logic. Since tunnelling requires > generating HTTP requests, it is something that can not > simply be hidden in a socket factory or connection manager. > In HttpClient 3.x, the method director knows about > tunnelling. That class is rather inflexible and designed > exclusively for a blocking scenario. Reworking it is > another major effort. I'd like to have an interface where > you feed in a few parameters and which then tells what > to do next: create a tunnel, retry with authentication, > follow a redirect, and so on. This might be an occasion > to revisit HTTPCLIENT-63. > https://issues.apache.org/jira/browse/HTTPCLIENT-63 > Let us just port the method director to HttpCore and then see what needs to be refactored and what could be improved. > c) Determine socket security dynamically. > This point is somehow separate from connection interfaces, > but I stumbled across it again when implementing the default > socket connection operator. I'd like to have a method > SocketFactory.isSecure(Socket) > to query dynamically whether a socket should be considered > secure or not. I dislike instanceof checks to determine > object behavior. They tie runtime properties to a static > class hierarchy. > This change should not take more than a few hours to > implement. I'd like to get some feedback on the idea, > then I would tackle it on the next free weekend. > Give it a shot 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]
