<div>Not changing variables out from under executing JavaScript makes a lot of sense, but if that was the case then it's not clear when the readyState could be updated. The spec states "<span class="Apple-style-span" style="font-family: sans-serif; font-size: medium; ">When the <i>Web Socket connection is closed</i>, the <code title="dom-WebSocket-readyState" style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); "><a href="http://dev.w3.org/html5/websockets/#dom-websocket-readystate" style="color: inherit; background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; ">readyState</a></code> attribute's value must be changed to <code title="dom-WebSocket-CLOSED" style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); "><a href="http://dev.w3.org/html5/websockets/#dom-websocket-closed" style="color: inherit; background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; ">CLOSED</a></code> (2), and the user agent must <span style="border-bottom-style: solid; border-bottom-color: rgb(153, 153, 204); border-bottom-width: initial; ">queue a task</span> to <span style="border-bottom-style: solid; border-bottom-color: rgb(153, 153, 204); border-bottom-width: initial; ">fire a simple event</span> called <code title="event-close" style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); ">close</code> at the <code style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); "><a href="http://dev.w3.org/html5/websockets/#websocket" style="color: inherit; background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: transparent; ">WebSocket</a></code> object.<span class="Apple-style-span" style="font-size: small; ">" If the browser cannot mutate the readyState until JavaScript stops running then it would either have to either enqueue a second task to change readyState at some point in the future or set the readyState right before dispatching the 'close' event. The latter would be much nicer to implement - but then it does make the readyState completely useless as it would always be exactly equivalent to the last event that was fired on a given WebSocket.</span></span></div>
<div><br></div><div>The spec seems to be also a bit undecided about error handling. The postMessage() description says "<span style="font-family: sans-serif; font-size: medium; "> If the connection is not established (<code title="dom-WebSocket-readyState" style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); "><a href="http://dev.w3.org/html5/websockets/#dom-websocket-readystate" target="_blank" style="color: inherit; background-repeat: initial; background-color: transparent; ">readyState</a></code> is not <code title="dom-WebSocket-OPEN" style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); "><a href="http://dev.w3.org/html5/websockets/#dom-websocket-open" target="_blank" style="color: inherit; background-repeat: initial; background-color: transparent; ">OPEN</a></code>), it must raise an <code style="font-size: inherit; font-family: monospace; font-variant: normal; color: rgb(255, 69, 0); ">INVALID_STATE_ERR</code> exception.<span style="font-size: small; ">" The first part implies that trying to postMessage() when the underlying socket is disconnected requires an exception to the thrown synchronously, but if the readyState cannot be changed while javascript is running then the parenthetical would indicate that a browser could not throw an exception until the readyState was updated.</span></span></div>
<div><font class="Apple-style-span" face="sans-serif"><br></font></div><div><font class="Apple-style-span" face="sans-serif">An exception for 'too much data pending' has a similar problem - there's no way for the browser to know that there is too much data enqueued without blocking to check with its I/O thread (or process). An asynchronous model would be better with an error signaled by a later callback.</font></div>
<div><font class="Apple-style-span" face="sans-serif"><br></font></div><div><font class="Apple-style-span" face="sans-serif">I think a better way to do error handling is to have an asynchronous onerror callback or event when the browser notes that a message did not make it to the other side.</font></div>
<div><font class="Apple-style-span" face="sans-serif"><br></font></div><div><font class="Apple-style-span" face="sans-serif">- James</font></div><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 4:52 PM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Does disconnect() attempt to flush pending messages or drop them?<div><br></div><div>There isn't a way to determine if the WebSocket is successfully sending the postMessage data? For all the caller knows, its just backing up and not going anywhere.</div>
<div><br></div><div>Something that might add value is an onmessagesent event that fires after a postMessage has put the bits on the wire.</div><div><br></div><div>postMessage() may want another exception condition... 'too much data pending exception'... consider calling postMessage in a while(true) loop... at some point the system is going to have to give up queing the data if its not actually making its way out on the wire.</div>
<div><div></div><div class="h5">
<div><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 1:19 PM, Kelly Norton <span dir="ltr"><<a href="mailto:knorton@google.com" target="_blank">knorton@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Oh and one more thing:<div><br></div><div>Doesn't it seem strange that disconnect() causes an onclose event to be dispatched? Should the method not be close() to be consistent with open(), onopen, onclose?</div><div>
<br>
</div><div>/kel<div><div></div><div><br><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 4:14 PM, Kelly Norton <span dir="ltr"><<a href="mailto:knorton@google.com" target="_blank">knorton@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One thing about postMessage that I'm curious about. Since it has to report failure synchronously by throwing an INVALID_STATE_ERR, that seems to imply that all data must be written to a socket before returning and cannot be asynchronously delivered to an I/O thread without adding some risk of silently dropping messages. Seems like the right choice would be to allow outbound messages to drop, which would mean that developers would be forced to do their own handshaking.<div>
<br></div><div>I'm also not sure there is good coverage of error conditions in the spec. The only methods of error notification are exceptions in postMessage and onclose. I had assumed that a WebSocket that fails to connect would invoke onclose asynchronously, but I didn't see that in the spec. Without that you don't even have the ability to know if a socket failed to establish a connection (short of readyState polling). The spec also doesn't indicate that the readyState should transition to CLOSED on connection failure. (Description of the disconnect() method is careful to mention that it closes a connection or a connection attempt, but description of when onclose is fired just mentions a connection closing). I definitely think there should be a way to receive an event if a connection fails to establish; I would hate to have to poll another readyState.</div>
<div><br></div><div>/kel</div><div><br></div><div><div><div></div><div><div class="gmail_quote">On Fri, Jun 26, 2009 at 1:34 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">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>Yes, but the "closed" state of a given WebSocket doesn't have to exactly match the state of the underlying TCP connection, in the same way that document.cookies doesn't exactly match the current set of cookies that the network stack may be tracking (they can differ when HTTP responses are received in the background while JS is executing).</div>
<div><br></div><div>So if the remote server closes the TCP connection, it generates a "close" event which marks the WebSocket as closed. It means that you could have a situation where you post messages to a WebSocket which aren't received by the server because the connection is closed, but that's true regardless due to the asynchronous nature of the networking protocol.</div>
<div><br></div><div>-atw</div><div><div></div><div><div><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 9:52 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div><div class="gmail_quote">On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">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><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></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><font color="#888888"><div>-Darin</div>
</font></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br>If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States).<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States).<br>
</div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br>