Re: Mozilla/Cisco API Proposal - listening

On 12 July 2011 07:52, Cullen Jennings <fluffy@cisco.com> wrote:

> Ian, I apologize for asking this again because I remember seeing that you had posted an answer to the question I am about to ask somewhere else but I can't find it.. In the general case of using the API outside browsers, or even in browsers, how does one solve the race condition that happens after creation of the object and before installing the onIncomgStream callback and the arrival of the first incoming stream? Are they queued ?

I asked a couple of our JS people here at Mozilla about this today.
The short answer is, "Yes, they're queued."

Longer answer:

While the constructor my form connections and add the corresponding
notification events to the queue, those won't actually be dispatched
until after a context switch out of the javascript interpreter. This
is known as the "run to completion" model, where one can generally
expect a script fragment (within a tag or the body of an event handler
function) to execute completely before another event is dispatched.

In fact, the example code for MediaStreamRecorder in Ian's proposal
adds event handlers to an XMLHttpRequest object *after* calling its
explicit send() method.

The PeerConnection case is complicated by the constructor's
signalingCallback argument. The user agent must use this as part of
session discovery and so it will be calling back into the script from
inside the contructor. The implementation of signalingCallback is
expected to use (asynchronous) XHR, so a separate event loop must be
run for this. I'm told, at least in Mozilla's codebase, it is possible
to sandbox/nest this event loop to prevent interactions with the event
loop of the outer frame.

Tangentially, Anant had mentioned preferring callbacks to events where
possible. In discussing the issue above, it was pointed out that
calling into javascript from complex native code increases the
exploitable surface available to interpreter bugs, vs what happens
when the same code is called later as an event hander. While I agree
passing callbacks directly is lighter weight from the client's
perspective, there is a security reason to prefer the narrow interface
of an event. For what that's worth.

Does that answer your question?

 -r

--
Ralph Giles - Mozilla Video team

Received on Wednesday, 13 July 2011 00:11:33 UTC