- From: Michael Nordman <michaeln@google.com>
- Date: Fri, 26 Jun 2009 16:49:18 -0700
On Fri, Jun 26, 2009 at 4:34 PM, Jeff Walden <jwalden+whatwg at mit.edu<jwalden%2Bwhatwg at mit.edu> > wrote: > On 26.6.09 13:52, Michael Nordman wrote: > >> There isn't a way to determine if the WebSocket is successfully sending >> the postMessage data? For all the caller knows, its just backing up and >> not going anywhere. >> > > You can't really know data has been successfully sent until you get a > response that acknowledges it. Getting it "on the wire" doesn't mean it'll > actually be received; I'm not really sure how much value knowing that's > happened actually has, other than for doing network diagnostics (which > hardly seems a use case to support). Progress bars are routinely implemented without get hi-level application acks from the other side. XMLHttpRequest.upload.onprogress is one such example. > diagnostics Cell-phone signal strength bars are a form of diagnostics... existence proof of diagnostics being a significant use case. > > > > postMessage() may want another exception condition... 'too much data >> pending exception'... consider calling postMessage in a while(true) >> loop... at some point the system is going to have to give up queing the >> data if its not actually making its way out on the wire. >> > > Nothing prevents the data from being thrown in a FIFO queue until it > actually can be sent, and I don't see a reason why OOM in the event queueing > failed should be handled differently from any other OOM. This info about the status of the WebSocket would be easy to provide to callers of this API. There are easily found valid use cases for this additional status info. What compelling reason is there to not do so? Seems like low-hanging fruit if you ask me. > > > Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090626/7d5fce20/attachment.htm>
Received on Friday, 26 June 2009 16:49:18 UTC