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

Re: Proposal related to bug 22270 "Adding tracks to MediaStream should only be possible for constructed streams"

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 25 Oct 2013 11:15:10 -0700
Message-ID: <CABkgnnW0ahmVDp_ToUg=Zs_3wfQqeHXnTEQmWXbbN9t1ndXLxw@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 25 October 2013 11:04, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> On 25/10/13 19:04, Martin Thomson wrote:
>> On 25 October 2013 03:43, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>> Is there value in having the UA police whether or not one can add tracks
>>>> to an UA-constructed MediaStream?
>>
>> I have no reasons to prevent this.  I appreciate the reasons roc
>> outlines, but honestly, most of the real machinery here is on the
>> tracks, not the container.
>
> The only case when I can see it could matter is:

I'm fairly sure that wouldn't happen.  Since the JS is going to see a
fixed view of the current state of the streams (that's the contract
the browsers need to guarantee regardless of what we define), it will
either see track X or not.  If it sees it, it can add it.

Maybe it's conforming to the contract that is going to be hard.  I
never had much difficulty with these sorts of races when building
plugins, and I'd imagine that browsers have far more sophisticated
tools for this, since this happens for more than just WebRTC.
Received on Friday, 25 October 2013 18:15:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:20 UTC