[whatwg] Issues with Web Sockets API

[Drew Wilson]

On Fri, Jun 26, 2009 at 3:47 PM, Michael Nordman <michaeln at google.com>wrote:

>
>
> No. But the difference is each XHR tells you when its been sent and gives
> you the response when its received. With this info, apps can rate limit
> things. WebSocket.postMessage doesn't tell you when that message has been
> sent.
>

Well, yes and no.

You know when you get a response back because readyState = HEADERS_RECEIVED.
But there's nothing between OPEN and HEADERS_RECEIVED that tells you
anything about bits on the wire.


>
> Suppose your sending 'i'm alive' messages. If the message you sent 5
> minutes ago hasn't really been sent, you wouldn't want to queue another 'i'm
> alive'.
>

If your goal is never to send another heartbeat until you know your previous
one has been delivered, then that seems like a motivation to add an
app-layer heartbeat ack. Treating "queued but not yet put on the wire" any
differently from "put on the wire but not yet acked" or "acked, but still
queued for delivery to the app layer on the remote end" seems like a false
distinction.


>
> If you're uploading a large data set incrementally across many distinct
> postMessage calls (perhaps to leave room for other control messages
> interspersed amoungst them, or to present progress info), how do you know
> when to queue more data to be sent.
>

I could keep saying "app level acks!" but I don't want to beat a dead horse,
and honestly, I'm not entirely certain that I'm right :)


>
>
>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090626/f4715779/attachment-0002.htm>