On Thu, 2007-02-08 at 20:07 +0100, Roland Weber wrote: > 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.
Hi Roland, I am perfectly fine with having NIO extensions for HttpConn. Oleg > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
