[whatwg] Issues with Web Sockets API

[Michael Nordman]

On Sat, Jun 27, 2009 at 3:18 PM, Jeff Walden
<jwalden+whatwg at mit.edu<jwalden%2Bwhatwg at mit.edu>
> wrote:

> 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
>> example.
>>
>
> 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
> establish).
>
>
>   > 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
> made.
>
> Jeff
>

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
world.

As for complexity.... websocket.onmessagesent attribute hardly qualifies?

I stand by my low hanging fruit characterization :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090629/734330a7/attachment.htm>