[whatwg] Issues with Web Sockets API

[Michael Nordman]

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-0002.htm>