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

On 25/10/13 06:12, Harald Alvestrand wrote:
> 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?

I think that is the core question to answer. It makes things a little 
bit cleaner IMHO, but the question is whether or not that motivates this 
change.

>
> (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 10:44:17 UTC