Hi Oleg, > 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.
No objections. But as I said before: when alpha 4 is out, we should discuss scope and location. I feel that NIO has outgrown HttpCore considerably. > 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. I was not going so far as to think there would be a unifying API. I'm dreaming of a similar split of concerns between BIO and NIO, with HttpConn-NIO being a module that makes use of only some of the classes and interfaces in HttpConn. For example the representation of routes, currently provided by HostConfiguration. > 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. If we can figure out how to map the route building stuff (connect, tunnel, layer SSL) to NIO, I can see that happening. But there's a long way to go yet. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
