- From: Philipp Serafin <phil127@gmail.com>
- Date: Tue, 22 Jul 2008 19:23:07 +0200
On Tue, Jul 22, 2008 at 6:47 AM, Shannon <shannon at arc.net.au> wrote:
> wait for connection;
> receive persistent connection request;
> pass request body to service;
> response = read from service;
> response_length = length of response;
> send Content-Length: $response_length;
> send $response
> close request or continue
>
> A threaded wrapper could queue multiple requests and responses.
>
> In theory (as I have yet to perform tests) this solution solves all
> websocket goals:
[...]
> Asynchronous: Requests and responses can be pipelined, meaning requests and
> responses can be transmitted simultaneously and are queued.
I think the problem is that this definition of "asynchronous" is very
narrow. Yes, you don't need to wait for a request to finish before you
issue a new one. But you'd still be bound to HTTP's request/response
scheme in general.
However, web authors might want to employ other schemes as well, for
example server-sided asynchronous notifications ("pushing"),
client-sided notifications that don't need to be replied or requests
that can be answered out-of-order. Things like this could be
implemented easily on top of the current WebSocket proposal, but would
be very complicated to do with HTTP.
If desired, maybe we could add an API to XHR to control pipelining though?
Regards,
Philipp Serafin
Received on Tuesday, 22 July 2008 10:23:07 UTC