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

On 10/24/2013 08:56 PM, Martin Thomson wrote:
> This might be overly constraining.  It's not necessary for the
> platform-constructed objects to have a constructor.  But it would be
> nice if applications could do the following:
>
> var mediaStream = new MediaStream(...)
> plaformMediaStream instanceof MediaStream // === true
>
> have you considered the possibility of having addTrack/removeTrack
> throw on platform-constructed streams, i.e.:
>
> // [NoInterfaceObject]
> function PlatformMediaStream() {
>      MediaStream.apply(this, [].concat.apply(arguments));
> }
> PlatformMediaStream.prototype = new MediaStream();
> function notAllowed() {
>     throw new Error('operation not permitted');
>     // or use DOMError as appropriate, I'm no longer able to follow that thread
> }
> PlatformMediaStream.prototype.addStream = notAllowed;
> PlatformMediaStream.prototype.removeStream = notAllowed;

Hmm. Are you suggesting that the UA do tis, or that an adapter could do 
this?
I think that if we followed Stefan's proposal, a JS user could do:

var nonPlatformMediaStream = new MediaStream(aPlatformMediaStream)

and get the same result as with the current spec (where adding and 
removing streams is allowed).

So the question on the table is:

Is there value in having the UA police whether or not one can add tracks 
to an UA-constructed MediaStream?

(since it's clear that JS can make whatever streams it needs after that 
point)


>
> On 24 October 2013 04:19, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> Hi, this relates to bug 22270,
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22270, that proposes to
>> allow adding/removing tracks from a (by the app) constructed MediaStream
>> only. Platform generated MediaStreams (those coming from getUserMedia,
>> and on the remote side of a PeerConnection) should not have those methods.
>>
>> We could spec that by having completely independent IDLs for
>> "Constructed" and "Platform" MediaStream's, but since there is such a
>> large overlap between them it seems more efficient to use a base
>> description that they both extend.
>>
>> I've sketched on two alternatives. The second one (Alternative B)is
>> inspired by Web Worker's (and its AbstractWorker) with an
>> AbstractMediaStream which is "implemented" by Platform/Constructed
>> MediaStreams. The first one (alternative A) uses inheritance instead of
>> "implements".
>>
>> I'm far from a WEBIdl expert, but to me Alternative A seems better in
>> that we can specify consumers be able to consume the "BaseMediaStream"
>> only, and would not have to worry about updating them if we would ever
>> add another type of MediaStream (that inherits from BaseMS). If we go
>> with alternative B we would have to spec that every consumer can handle
>> two types of MediaStream's for now (PlatfromMediaStream and
>> ConstructedMediaStream), and would have to update them if we add another
>> type in the future.
>>
>> Are there any comments or opinions? (And yes, the names are horrible.)
>>
>> Stefan
>>
>>
>>
>>
>> Alternative A
>> =============
>> interface BaseMediaStream : EventTarget {
>>               readonly    attribute DOMString    id;
>>               sequence<MediaStreamTrack> getAudioTracks ();
>>               sequence<MediaStreamTrack> getVideoTracks ();
>>               MediaStreamTrack?          getTrackById (DOMString trackId);
>>               readonly    attribute boolean      active;
>>                           attribute EventHandler oninactive;
>> };
>>
>>
>> interface PlatformMediaStream : BaseMediaStream {
>>                           attribute EventHandler onaddtrack;
>>                           attribute EventHandler onremovetrack;
>> };
>>
>>
>>
>> [Constructor,
>>                   Constructor (BaseMediaStream stream),
>>                   Constructor (MediaStreamTrackSequence tracks)]
>> interface ConstructedMediaStream : BaseMediaStream  {
>>               void                       addTrack (MediaStreamTrack track);
>>               void                       removeTrack (MediaStreamTrack
>> track);
>> };
>>
>>
>> Alternative B
>> =============
>> [NoInterfaceObject]
>> interface AbstractMediaStream {
>>              readonly    attribute DOMString    id;
>>              sequence<MediaStreamTrack> getAudioTracks ();
>>              sequence<MediaStreamTrack> getVideoTracks ();
>>              MediaStreamTrack?          getTrackById (DOMString trackId);
>>              readonly    attribute boolean      active;
>>                          attribute EventHandler oninactive;
>> };
>>
>>
>> interface PlatformMediaStream : EventTarget {
>>                          attribute EventHandler onaddtrack;
>>                          attribute EventHandler onremovetrack;
>> };
>> PlatformMediaStream implements AbstractMediaStream;
>>
>>
>> [Constructor,
>>                  Constructor (ConstructedMediaStream stream),
>>                  Constructor (PlatformMediaStream stream),
>>                  Constructor (MediaStreamTrackSequence tracks)]
>> interface ConstructedMediaStream  : EventTarget {
>>              void                       addTrack (MediaStreamTrack track);
>>              void                       removeTrack (MediaStreamTrack track);
>> };
>> ConstructedMediaStream implements AbstractMediaStream;
>>

Received on Friday, 25 October 2013 04:12:25 UTC