[whatwg] Issues with Web Sockets API

[Jeremy Orlow]

On Mon, Jul 6, 2009 at 9:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> > 1) The 'readyState' attribute can never actually be used by an
> application
> > and is redundant.
> >
> > Initially, the 'readyState' attribute is set to CONNECTING, but while
> > the object is in this state the user is not permitted to interact with
> > the WebSocket in any way.  The only useful thing that a user could do is
> > set event handlers and wait for the 'open' event to fire.  When the
> > WebSocket becomes connected, the readyState becomes 1 and the 'open'
> > event is fired. Once the WebSocket is open, the spec states that
> > whenever the connection is closed the readyState changes to CLOSED and a
> > 'close' event is enqueued. 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.  A user will have to wrap all calls to postMessage() (or
> > send() if the function is renamed) in a try/catch block in order to
> > handle INVALID_STATE_ERRs.  Once the 'close' event has been received the
> > readyState attribute is useless since the state of the WebSocket is
> > known and can never change.
> >
> > I think 'readyState' should just go away since an application will have
> > to keep track of state updates through the fired events and use
> > try/catch blocks around all API calls anyway.
>
> The attribute is mostly present for debugging purposes. I wouldn't expect
> anyone to actually use it for production work.


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.)

Also, maybe it should be noted as such in the spec?


> On Fri, 26 Jun 2009, James Robinson wrote:
> >
> > 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 "When the *Web Socket
>
> > connection is closed*, the readyState attribute's value must be changed
> > to CLOSED (2), and the user agent must queue a task to fire a simple
> > event called close at the WebSocket object." 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.
>
> I've left it as is (the attribute changes on the fly), which is possibly
> risky, but more consistent with how such attributes are handled in
> general.


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?


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?

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090714/41bef7ed/attachment-0001.htm>