[whatwg] Websockets Client API
robert at ocallahan.org
Sun Feb 20 18:51:29 PST 2011
On Mon, Feb 21, 2011 at 2:34 PM, Bruce Atherton <bruce at callenish.com> wrote:
> 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
For every event in that section, the user-agent must queue a task to fire
the event. None of the other sections describe any events.
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.
HTML5 event loop. That task must run to completion before other tasks queued
by the user-agent will run.
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?
Yes. You observe correctly that the Web author has to be careful to ensure
that the event handlers are set on the Websocket object during the same task
that created it. However, this is a fairly natural requirement that is
common in the Web platform.
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.
Yeah :-). By "perfectly clear" I meant that the spec was "unambiguous",
rather than "obvious to the casual reader" :-).
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
More information about the whatwg