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

This sounds good to me.  I was going to go even further and suggest
that track sets in MediaStream could be made immutable, but that
changes the model we've been assuming too much.

That's not to say that it couldn't be made to work, just that I can't
sufficiently justify that dramatic a change.  This looks to be a good
way to deal with the problem.

On 16 April 2013 16:09, Robert O'Callahan <robert@ocallahan.org> wrote:
> To be concrete, here's what I think we should do:
>
> -- Introduce a new subtype of MediaStream, let's call it BundleMediaStream
> but I don't care what it's called. This stream represents a bundle of tracks
> from other MediaStreams, where the application controls the track set.
> -- Move the current MediaStream constructors to BundleMediaStream.
> -- Move addTrack/removeTrack to BundleMediaStream.
> -- Specify that for MediaStreams other than BundleMediaStream, the UA always
> controls the track set.
>
> This means for any MediaStream, either the UA controls the track set, or the
> application does, but not both. I think this is a helpful simplification for
> implementations and at the spec level.
>
> How does that sound?
>
> A reasonable alternative that requires less new syntax would be to make
> addTrack/removeTrack throw an exception when called on a MediaStream that
> wasn't constructed via a MediaStream constructor. However, I think
> introducing a new type is cleaner.
>
>
> 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 Wednesday, 17 April 2013 21:00:08 UTC