On Thu, 2007-02-08 at 18:30 +0100, Roland Weber wrote: > 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.
Roland, My position remains the same. Let us start _somewhere_ and get something that actually _works_. Once we have _something_ working, it is easier to observe commonalities in code and move components to a better home. I have worked extensively with both models and am very skeptical we can have a connection management abstraction that works reasonably well with both blocking and non-blocking I/O. NIO implies a totally different way of thinking, which does not mix well with APIs built around the classic I/O model. I am open to having HttpConn NIO at some point, but respectfully remain skeptical about the possibility of HttpConn being a unifying API for both blocking and non-blocking connection management. > > > 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. > I do not want to steer you in any particular direction, but personally tend to think of HttpAsync as HttpClient on top of HttpCore NIO. I would very much welcome HttpAsync dropping blocking I/O stuff altogether and concentrating on the non-blocking I/O model, which seems to fit better its stated goals. Cheers, 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]
