Hi Oleg, thanks for your feedback.
> (1) First off, I think we can safely keep NIO out of the picture. The > process of opening a connection in non-blocking mode is completely > different from that in the blocking one. > > * The user registers a request for a new connection with the connecting > I/O reactor: Ok. My general line of thought was to implement the connection.open(...) method so that it would take care of the registering. The question then would have been whether to block the calling thread or whether to set the connection to an intermediate state until the callback. Leaving it out of the picture (for now) will make things easier. > (3) I am still of an opinion that connection tunneling is a special case > and should be treated as such. I think essentially the connection should > be able to re-bind itself to a new socket. That is it. It should not be > aware of any tunneling aspects. I haven't warmed up to the "socket binding" concept yet. In particular, I'd hate to have a setSocket(...) method in the public interface. This is just begging to be abused in unforeseen ways. I think the data that needs to be accessible directly from the connection is: - open/closed, and if open... - where is it connected to (ultimate target, not proxy) - is it a secure connection >From that point of view, it should be possible to hide the tunnelling. However, the client needs to be aware whether the connection is direct or through a proxy, since requests sent to a proxy look different. If opening the socket is the responsibility of the connection, then there is no way around telling the connection whether it should go through a proxy or not. I need to think about this some more. > (4) We should start thinking about changing the socket factory interface > to enable support for detached sockets > https://issues.apache.org/jira/browse/HTTPCLIENT-475 Good point. Now that the factory is no longer in HttpCore, we're not restricted to the 1.3 API anymore. > (4) Let us try to not over-engineer and keep stuff simple. Fair. My problem currently is more the user safety than the engineering part :-) An API that is easy to misuse is hardly easy anymore, from a user perspective. >> interface: open while open >> For performance optimizations in HttpAsync as well >> as in a connection manager, it would be good if a >> connection can be opened without being closed explicitly. >> The idea is that it might be possible to avoid closing >> and re-opening, for example if different target hosts >> are accessed via the same proxy host. > > Agreed. This might also help with connection proxying / tunneling. I get a feeling that you would like to implement the calls to the socket factories outside of the connection. This raises the question of code reuse between HttpClient and HttpAsync. I'll focus on HttpClient for now, that will be tricky enough. >> implementation: split open/close from read/write > > May I suggest we leave this out for the first cut? No problem. If we leave NIO out of the picture, there is really no point at all to this split. The purpose would have been to switch between blocking and non-blocking opening of NIO connections. > Happy hacking > Thanks. I'll think about it some more today and tomorrow, then get started next Wednesday or so. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
