On Mon, Apr 15, 2013 at 11:28 PM, Stefan Håkansson LK < stefan.lk.hakansson@ericsson.com> wrote: > There are some use-cases which can be handled better if add/removeTrack is > possible, but if complex to implement I would personally be open to omit > that from a first version (especially if we decide that synchronization > context spans all tracks originating from the same end-point, not only the > tracks in one MediaStream). We could add it as a later extension. > What does it mean for a script to remove a MediaStreamTrack from a gUM stream or a PeerConnection remote stream? Does that have any side effects? Maybe it's just me but it seems weird that a script could, say, swap the tracks between a gUM stream and a PeerConnection remote stream. It would be extra weird if we ever create any subclasses of MediaStream. Use-cases that need add/removeTrack can always construct their own MediaStream with borrowed tracks. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Monday, 15 April 2013 11:39:09 UTC