Good point. I guess it would be possible to continue reading more requests from a connection while responses are being generated & sent. It's not your typical use-case, and the list of pending responses would quickly grow, but it's certainly possible. I was thinking more along the lines of a connection where incoming traffic didn't cause outgoing traffic (or more precisely, the order of outgoing traffic is not intricately tied to the order of incoming traffic). Consider, for example, an asynchronous web-service where requests can be sent (without expecting an answer), and responses are sent whenever the server-side processing of the request completes (and thus in no particular order). I don't think a typical browser is capable of handling this, but if you could code your own Socket handling, it is useful.
Sam On 12/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Sam, > > > if your application requires reading & writing to > > happen independent of each other (not the case with HTTP > > Who says that? ;-) That's exactly what I had in mind > for the pipelining in HttpDispatch (fka HttpAsync)[1]. > > cheers, > Roland > > [1] http://wiki.apache.org/jakarta-httpclient/HttpAsyncThreadingDesign > > --------------------------------------------------------------------- > 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]
