W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

Re: addTrack/removeTrack on gUM streams and PeerConnection remote streams

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 18 Apr 2013 11:09:02 +0200
Message-ID: <516FB82E.9000509@ericsson.com>
To: robert@ocallahan.org
CC: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-04-17 12:23, Robert O'Callahan wrote:
> On Wed, Apr 17, 2013 at 10:18 PM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     Since they're only used to listen to when the UA updates the track
>     set they wouldn't be used when it's only the application that
>     manages the track set.
>
>     This is a bit confusing in the current spec. The description of the
>     events say that they are fired whenever a track is added, which is
>     misleading since they are not fired in the addTrack()/removeTrack()
>     algorithms. It's fixed for the next release.
>
>
> We should also fire them when addTrack()/removeTrack() are called,
> shouldn't we?

We currently don't do that since these methods directly adds or removes 
the track. In the case where it's the UA that modifiess the track set, 
the track is added/removed in the same event loop iteration as the 
addtrack/removetrack event is fired.

I don't have a strong preference about this; if we could find similar 
behavior in established APIs I would be happy to align.

/Adam
Received on Thursday, 18 April 2013 09:09:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:40 UTC