<div class="gmail_quote">On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</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"><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 9:18 AM, James Robinson <span dir="ltr"><<a href="mailto:jamesr@google.com" target="_blank">jamesr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>However, users can't usefully check the readyState to see if the WebSocket is still open because there are not and cannot be any synchronization guarantees about when the WebSocket may close. </div>
<div><br></div></span></blockquote><div> </div></div></div>Is this true? Based on our prior discussion surrounding cookies, it seems like as a general rule we try to keep state from changing dynamically while JS code is executing for exactly these reasons.
</blockquote></div><br><div><br></div><div>I think this is a very different beast. The state of a network connection may change asynchronously whether we like it or not. Unlike "who" may access cookies or local storage, the state of the network connection is not something we solely control.</div>
<div><br></div><div>-Darin</div>