Re: Mozilla/Cisco API Proposal - listening

Yep, that is totally answers it. Thanks. 



On Jul 12, 2011, at 17:10 , Ralph Giles wrote:

> 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


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Received on Wednesday, 13 July 2011 14:42:27 UTC