- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 29 Jun 2009 12:18:01 -0700
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>
Received on Monday, 29 June 2009 12:18:01 UTC