[whatwg] Websockets Client API

[Bruce Atherton]

On 20/02/2011 2:57 PM, Robert O'Callahan wrote:
> It's not magic, the spec is perfectly clear. The language about "queuing a
> task" ensures that any callback events fire after the current task (e.g. the
> script event handler that created the Websocket connection) has run to
> completion.
>

Perhaps you are reading a different spec than I am. The only language I 
see about queuing tasks involves changing the ready state on the 
Websocket object. There is nothing in there about waiting until a block 
of other Javascript code has run before making any other event callbacks.

Let me see if I follow the "perfectly clear" line of reasoning you are 
using. Your assumption is that a Websocket connection will only be 
loaded in an event handler like window.onload. No other events will be 
delivered until the current event handler finishes. And the event 
handler that creates the Websocket object will necessarily also be where 
the event handlers are set on the Websocket object. By making all of 
these assumptions, it becomes obvious that within a browser this API is 
safe for callbacks. Do I have that right?

I am reminded of a joke about mathematicians. One argues that it is 
obvious that claim A follows from B. The other disagrees. After arguing 
for an hour, the latter finally agrees that A obviously follows from B.