Re: Mozilla/Cisco API Proposal - listening

On Sat, 16 Jul 2011, Anant Narayanan wrote:
> On 7/15/2011 11:31 PM, Ian Hickson wrote:
> > > var conn = new PeerConection(...);
> > > conn.onRemoteStreamAdded = function(stream) {
> > >    console.log("stream was added");
> > > };
> > > conn.connect();
> > > 
> > > instead of omitting the connect() and hoping that your
> > > onRemoteStreamAdded callback will be called magically.
> > 
> > There's no magic here. The PeerConnection constructor invokes the 
> > signaling callback and as soon as the ICE agent has a stream 
> > negotiated, the event notifiying that a stream has been added is 
> > fired.
> 
> Yes, but what if the stream is established before you have a chance to 
> attach a callback?

It can't happen. First, the ICE agent doesn't actually begin processing 
until the next time the event loops spins. But even if it did, any queued 
tasks don't run until the next time the event loop spins either. The 
script that creates the PeerConnection() object itself blocks the event 
loop. It's exactly the same pattern as is used throughout the Web 
platform, e.g. for EventSource, WebSocket, HTMLImageElement (<img>), 
HTMLMediaElement (<video>), etc.


> > > It also makes clear the distinction between streams that were added 
> > > before the RTP negotiation happened, and those that were added after 
> > > and sets expectations accordingly.
> > 
> > No streams can be added from the remote peer before the ICE agent 
> > runs, since the ICE agent is how the UA learns of the remote streams. 
> > Do you mean local streams? Those wouldn't fire an event when added, so 
> > I don't really follow how it would help distinguish anything.
> 
> I do mean local streams. Streams added before are expected to start 
> transmitting immediately after the connection is established, but local 
> streams you add after will appear only after some delay because 
> parameters have to be renegotiated.

Streams you add when you create the PeerConnection are sent as part of the 
initial offer, which is only sent once the event loop next spins, which 
can't happen until after you've added all the streams you want and the 
script has finished executing.


> Speaking strictly as a JS programmer I find the earlier model a little 
> uncomfortable. Whenever I add a callback or event listener in JS code, I 
> always attach them first and only after that do the thing that would 
> cause them to be fired.

This is unnecessary. Events on the Web are not re-entrant. (With some 
exceptions, but those aren't relevant here.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 16 July 2011 19:53:57 UTC