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.
