<br><br><div class="gmail_quote">On Mon, Jul 6, 2009 at 9:30 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> 1) The 'readyState' attribute can never actually be used by an application<br><div class="im">
> and is redundant.<br>
><br>
> Initially, the 'readyState' attribute is set to CONNECTING, but while<br>
> the object is in this state the user is not permitted to interact with<br>
> the WebSocket in any way.  The only useful thing that a user could do is<br>
> set event handlers and wait for the 'open' event to fire.  When the<br>
> WebSocket becomes connected, the readyState becomes 1 and the 'open'<br>
> event is fired. Once the WebSocket is open, the spec states that<br>
> whenever the connection is closed the readyState changes to CLOSED and a<br>
</div>> 'close' event is enqueued. However, users can't usefully check the<br>
<div class="im">> readyState to see if the WebSocket is still open because there are not<br>
> and cannot be any synchronization guarantees about when the WebSocket<br>
</div><div class="im">> may close.  A user will have to wrap all calls to postMessage() (or<br>
> send() if the function is renamed) in a try/catch block in order to<br>
> handle INVALID_STATE_ERRs.  Once the 'close' event has been received the<br>
> readyState attribute is useless since the state of the WebSocket is<br>
> known and can never change.<br>
><br>
> I think 'readyState' should just go away since an application will have<br>
> to keep track of state updates through the fired events and use<br>
> try/catch blocks around all API calls anyway.<br>
<br>
</div>The attribute is mostly present for debugging purposes. I wouldn't expect<br>
anyone to actually use it for production work.</blockquote><div><br>Is there precedent for other portions of the API that are mostly for debugging purposes?  (I can't think of anything off the top of my head.)<br><br>
Also, maybe it should be noted as such in the spec?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Fri, 26 Jun 2009, James Robinson wrote:<br>
<div class="im">
><br>
> Not changing variables out from under executing JavaScript makes a lot<br>
> of sense, but if that was the case then it's not clear when the<br>
> readyState could be updated.  The spec states "When the *Web Socket<br>
</div><br>> connection is closed*, the readyState attribute's value must be changed<br>
<div class="im">> to CLOSED (2), and the user agent must queue a task to fire a simple<br>
> event called close at the WebSocket object." If the browser cannot<br>
> mutate the readyState until JavaScript stops running then it would<br>
> either have to either enqueue a second task to change readyState at some<br>
> point in the future or set the readyState right before dispatching the<br>
> 'close' event.  The latter would be much nicer to implement - but then<br>
> it does make the readyState completely useless as it would always be<br>
> exactly equivalent to the last event that was fired on a given<br>
> WebSocket.<br>
<br>
</div>I've left it as is (the attribute changes on the fly), which is possibly<br>
risky, but more consistent with how such attributes are handled in<br>
general.</blockquote><div><br>If it's only for debugging purposes, maybe a cleaner way to define it is to simply be the last event fired on a given WebSocket?<br><br><br>One other random question:  in the IDL for WebSockets, the three constants for ready state are all defined as shorts but the value of ready state is a long.  Is this an oversight?<br>
<br>J<br></div></div>