<br><br><div class="gmail_quote">On Sat, Jun 27, 2009 at 3:18 PM, Jeff Walden <span dir="ltr"><<a href="mailto:jwalden%2Bwhatwg@mit.edu">jwalden+whatwg@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="it">On 26.6.09 16:49, Michael Nordman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Progress bars are routinely implemented without get hi-level application<br>
acks from the other side. XMLHttpRequest.upload.onprogress is one such<br>
example.<br>
</blockquote>
<br></div>
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).<div class="it">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> diagnostics<br>
<br>
Cell-phone signal strength bars are a form of diagnostics... existence<br>
proof of diagnostics being a significant use case.<br>
</blockquote>
<br></div>
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.)<div class="it">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This info about the status of the WebSocket would be easy to provide to<br>
callers of this API. There are easily found valid use cases for this<br>
additional status info. What compelling reason is there to not do so?<br>
Seems like low-hanging fruit if you ask me.<br>
</blockquote>
<br></div>
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.<br>
<font color="#888888">
<br>
Jeff<br>
</font></blockquote></div><div><br></div><div>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. </div>
<div><br></div><div>As for complexity.... websocket.onmessagesent attribute hardly qualifies?</div><div><br></div><div>I stand by my low hanging fruit characterization :)</div>