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
