On Wed, 2007-02-07 at 17:06 +0100, Roland Weber wrote: > Hi Oleg, > > > Actually, HttpCore NIO is fully HTTP pipelining capable. > > I just need to add ability to queue requests / responses > > to the default protocol handlers. So, we'll have a full-blown > > HTTP pipelining support in HttpCore 4.0 > > I may be wrong, but I tend to think that it takes a little more > than just a queue or two. If you have a pipeline open, you want > to pick a request that can be sent through that pipe rather than > the first in the queue. If you're going to open a new connection, > you want to skip requests that fit into an open pipeline, at least > if the connections-per-host limit is exceeded. Of course with > safeguards that prevent requests from starving. There's pipelines > that are open, such that are closed for writing (after a request > with connection: close or HTTP/1.0 without content length), and > such that are temporarily closed for writing (waiting for a 100 > continue response). Then you should have handling for re-sending > requests if a pipeline is terminated prematurely (after a response > with connection: close). > All those are things that an HttpDispatcher was supposed to take > care of. HttpCore-NIO (emphasis on _core_) already subsumes > responsibilities of HttpConn, now HttpAsync is to follow.
How come? > How > much more do you want to squeeze into it? > > On a related matter, I'm getting a little frustrated here. I've > invested considerable time first into HttpAsync and more recently > into HttpConn, coming from a blocking IO perspective. If the > responsibilities of these two components are so easily addressed > by adding just a little here and there in Http-NIO, then let's > send HttpConn the same way that HttpAsync has already gone and > put HttpClient directly on top of NIO. Oh my god! C'mon, Roland. Do you know how much of my time and hard work I put into HttpClient 3 is going to get thrown into the rubbish bin? I said this before, I'll say it again: NIO makes no frigging sense for pure clients or pure servers. The complexity of NIO is simply not worth it. Blocking HTTP with a reasonable threading strategy will always outperform non-blocking one at a fraction of complexity of the latter. NIO makes sense for middle-tier services like message mediators and reverse proxies. Oleg > I'm not going to spend my time on implementing very tricky and > mostly redundant functionality for a measly 10% performance > advantage that blocking IO may have over NIO. I can happily > write user documentation and leave the NIO coding to you. > > When HttpCore alpha4 is out, we should reassess the scope, > location and roadmap for our components and modules. > > 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]
