I went through exactly the same exercise some days ago.
It turns out that the perfectly clear specification is the
specification of the Javascript runtime environment, not in the
particular API specification.
obTangentEven in that case, I would prefer to see a separate open
call. It's just
I believed that the browser is expected to somehow magically delay the
events until a callback has been registered. At least that is how it
seems to work at the moment. The specification could be clearer about
this.
While IETF and W3C are involved in standardizing the protocol, the
part you are
On Mon, Feb 21, 2011 at 11:38 AM, Toni Ruottu toni.ruo...@iki.fi wrote:
I believed that the browser is expected to somehow magically delay the
events until a callback has been registered. At least that is how it
seems to work at the moment. The specification could be clearer about
this.
Forgive me if I'm overlooking something here but couldn't the same thing
be accomplished by wrapping the constructor code in a try/catch block?
Anthony
On 02/20/2011 04:09 PM, Bruce Atherton wrote:
I know that the IETF HyBi WG is defining the Websockets protocol, but I
believe that the
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
Sorry, I don't understand what you mean. The constructor is not throwing
an exception in this case. The issue I am concerned with is that the
Websocket object can potentially be used before it has been configured
with event handlers, although it sounds like that may not be an issue in
On Mon, Feb 21, 2011 at 2:34 PM, Bruce Atherton br...@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
