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 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. 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]
