Hi all, regarding HTTPCLIENT-602 (formerly HTTPCORE-8) https://issues.apache.org/jira/browse/HTTPCLIENT-602 I'd like to share my ideas and get your feedback. Here is a more or less random collection...
interface: open, target Opening a connection should be possible as long as it is closed. For traditional blocking connections and (Secure)SocketFactory, we need to specify the target host and optionally the proxy host to which to connect. That can be done by separate setters before opening, or as arguments to an open method. I prefer the latter, how about you? 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. I'd rather leave this out initially. Oleg has to remind me on a regular basis that a series of smaller steps is better than a big jump. Not this time ;-) connection states Currently, a connection is either open or closed. That's fine with the blocking IO model. It's also good enough for HttpCore, since we don't have an open() method there. If we had an asynchronous open() method, that is one that returns immediately and leaves the actual opening to an event handling thread, we'd have a third state: "opening". You can't use the connection for reading or writing yet because it's not open, but you can't open it either since that operation is already in progress. I'd really like to get input on that one, given my lack of experience with NIO. Should we have an asynchronous open method in the first place? Or make the open call blocking even for a NIO connection? Leave NIO totally aside in HttpClient/HttpConn? (I wouldn't like that.) If we introduce a third state, what's the behavior of read/write methods while in that state? Throw an exception or block until open? Should we define separate interfaces for traditional and NIO connections? implementation: split open/close from read/write In the initial patch I provided for HTTPCORE-8, the connection implementation was a container for a socket. The connection "knows" how to write to and read from a socket, using IO or NIO depending on the implementation. Opening and closing was delegated to a different object, there called an operator. The advantage of this approach is that the open/close implementation is not tied to the actual connection implementation and it's read/write behavior. The drawback is an increased complexity of the interfaces. I am not sure how valuable the flexibility is that we would gain. Is there a need to freely combine different implementations for open/close and read/write? Or will we end up using only two combinations anyway, one for traditional IO and one for NIO? (or a single combination if NIO is left aside, see above) Is this another case where we should apply the small steps approach? I am most uncertain how NIO fits in here. I guess that's it for now. Thanks in advance for your thoughts on these matters, and for reminders about what I forgot. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
