[whatwg] Issues with Web Sockets API

[James Robinson]

Hello,

I'm very excited about the concept of web sockets and look forward to
building apps with it but the web sockets API at
http://dev.w3.org/html5/websockets/ has some issues.  Many issues seem to be
inherited from the original XmlHttpRequest specification, which was
extremely useful but not a very good spec.  I'm sure I'm not the only one
who has spent far too many hours dealing with underspecified or poorly
implemented XHR flavors and would love to avoid doing that in the future.  I
know several vendors have started work on implementations already but I hope
that this feedback is still useful.

0) postMessage() looks as if it is intended to mimic
MessagePort.postMessage() or , but the arguments and error conditions are
different.  While it would be conceptually nice to treat a web socket in the
same way as a message port, it's not possible to treat the two postMessage()
functions in the same way.  I'd recommend the WebSocket version be renamed
to something like "send()" to avoid confusion and false expectations.
 There's similar oddness with receiving events that satisfy the MessageEvent
interface - since all fields except 'data' will necessarily be invalid I
don't see the value in receiving something more complex.

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.

- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090626/6df6232f/attachment-0002.htm>