- From: Drew Wilson <atwilson@google.com>
- Date: Fri, 26 Jun 2009 16:10:14 -0700
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-0001.htm>
Received on Friday, 26 June 2009 16:10:14 UTC