On Mon, Feb 21, 2011 at 2:34 PM, Bruce Atherton 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
> Javascript code
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
browsers.
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
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 defini
On 2/17/11, Sebastian Herrlinger wrote:
> The only way to really access a device and do anything with it and its data
> would be JS,
Not in the OP case, which is about sending finite audio streams, encoded
in one of specified formats to a server for storage and distribution.
The simplest, and IMO
On Mon, Feb 21, 2011 at 11:38 AM, Toni Ruottu 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.
>
It's not magic, t
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 de
I know that the IETF HyBi WG is defining the Websockets protocol, but I
believe that the definition of the browser API is still done through
HTML5. If I am wrong, please let me know.
I've been reading through http://dev.w3.org/html5/websockets/ in an
effort to define a similar client interface
