Hi Oleg, > I still do not see how HttpCore NIO attempts to subsume the > responsibilities of HttpConn and HttpAsync since both modules are > currently based on blocking I/O model.
Maybe I did not find the appropriate words. I was talking about abstract responsibilities, not about implementation techniques. Since we've thrown Connection.open() out of HttpCore, I see the abstract responsibilities of HttpConn as: - open connections - tunnel/layer SSL - manage connections for re-use - enforce connection limits Currently there are only blocking interfaces and implementations (if any), which doesn't mean we couldn't put NIO interfaces and implementations for these _responsibilites_ there as well. If we would find an elegant way of separating NIO-core from NIO-conn functionality. We never discussed the exact scope of HttpAsync, and I kept on emphasizing that the _initial_ implementations would be based on blocking IO, because I don't know how to implement others. That doesn't mean there should not be non-blocking dispatchers. There should be. I just can't implement them, in particular not until I've figured out much more about the dispatching problem. The dispatching is what I consider the focus of HttpAsync in it's present form, with some background worker thread stuff thrown in as an implementation detail, because I'd need those to make it work with blocking IO. To me, it looks as if we're making a very nice split of responsi- bilites into Core, Conn, and others for the blocking implementation, while the NIO implementation just pushes everything into one module. The part that concerns me most about this is that the NIO module is in HttpCore. So we have a module HttpCore-main which can do very little without other modules, and a module HttpCore-NIO that does almost everything by itself. > Yes, one can use NIO to access file system objects but currently all > file system bound operations are _blocking_. Oh I see. Blocking non-blocking. A fake. > This is my personal vision of the HttpComponents stacks: > > (1) Blocking HTTP (mainstream) > HttpClient > HttpConn, HttpCookie, HttpAuth > HttpCore > > (2) Non-blocking HTTP (covers special use cases) > HttpAsync, HttpCookie, HttpAuth > HttpCore-NIO > HttpCore A traditional IO implementation of HttpAsync will make use of HttpConn. Probably not the connection managers there, but the connection interfaces and implementations, operators, and the auto-close logic. I'd also try to re-use the Http[Method]Director logic from HttpClient. A NIO implementation of HttpAsync might look much like current HttpNIO at the backend, while adding the auto-close logic, Http[Method]Director and application notification callbacks at the frontend. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
