<br><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 4:34 PM, Jeff Walden <span dir="ltr">&lt;<a href="mailto:jwalden%2Bwhatwg@mit.edu">jwalden+whatwg@mit.edu</a>&gt;</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 13:52, Michael Nordman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There isn&#39;t a way to determine if the WebSocket is successfully sending<br>
the postMessage data? For all the caller knows, its just backing up and<br>
not going anywhere.<br>
</blockquote>
<br></div>
You can&#39;t really know data has been successfully sent until you get a response that acknowledges it.  Getting it &quot;on the wire&quot; doesn&#39;t mean it&#39;ll actually be received; I&#39;m not really sure how much value knowing that&#39;s happened actually has, other than for doing network diagnostics (which hardly seems a use case to support).</blockquote>
<div><br></div><div>Progress bars are routinely implemented without get hi-level application acks from the other side. XMLHttpRequest.upload.onprogress is one such example.</div><div><br></div><div>&gt; diagnostics</div><div>
<br></div><div>Cell-phone signal strength bars are a form of diagnostics... existence proof of diagnostics being a significant use case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="it"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
postMessage() may want another exception condition... &#39;too much data<br>
pending exception&#39;... consider calling postMessage in a while(true)<br>
loop... at some point the system is going to have to give up queing the<br>
data if its not actually making its way out on the wire.<br>
</blockquote>
<br></div>
Nothing prevents the data from being thrown in a FIFO queue until it actually can be sent, and I don&#39;t see a reason why OOM in the event queueing failed should be handled differently from any other OOM.</blockquote><div>
<br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><font color="#888888">
<br>
Jeff<br>
</font></blockquote></div><br>