[whatwg] Issues with Web Sockets API
michaeln at google.com
Mon Jun 29 12:18:01 PDT 2009
On Sat, Jun 27, 2009 at 3:18 PM, Jeff Walden
<jwalden+whatwg at mit.edu<jwalden%2Bwhatwg at mit.edu>
> On 26.6.09 16:49, Michael Nordman wrote:
>> Progress bars are routinely implemented without get hi-level application
>> acks from the other side. XMLHttpRequest.upload.onprogress is one such
> That they can be implemented this way does not imply they must be
> implemented this way. I don't see why the acks users will pretty much
> invariably have (if they're implementing something so complex as to want
> data-sent events) layered atop the base WebSocket don't suffice for this
> (and more accurately than simple out-of-the queue status notifications can
> > diagnostics
>> Cell-phone signal strength bars are a form of diagnostics... existence
>> proof of diagnostics being a significant use case.
> Is WebSocket the optimal way to satisfy that use case? (Also, to be clear,
> I wasn't suggesting that diagnostics aren't interesting, but they seem quite
> orthogonal to the primary use case of supporting two-way message passing.)
> 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.
> The use case may be valid, but I don't see it as compelling. I don't see
> the gain as worth the added complexity to the interface, which at present is
> exactly as simple as it can be to support two-way message passing. I expect
> the messages passed will usually follow send-ack sequencing (in one
> direction or the other, and particularly for users who care about exact data
> transmission), in which case reception of an ack signals progress has been
I didn't lobby for a particular use case, so not sure which of the handful i
alluded to was deemed valid but not compelling. The point was there probably
is a use case that would be deemed compelling once it was unleashed on the
As for complexity.... websocket.onmessagesent attribute hardly qualifies?
I stand by my low hanging fruit characterization :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg