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

Re: Constructors and cloning

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 05 Nov 2013 18:03:31 +0100
Message-ID: <527924E3.8060501@alvestrand.no>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>, public-media-capture@w3.org
On 11/05/2013 06:47 AM, Adam Bergkvist wrote:
> On 2013-11-04 20:02, Harald Alvestrand wrote:
>> My alternate suggestion is to remove the constructor for
>> MediaStreamTrack until we have a good story on how we want to use naked
>> tracks; at the moment, no such compelling story has been told, as far as
>> I can tell, so I'd want to call that a "post version 1" feature.
>
> We can skip the MediaStreamTrack(kind, Constraints) constructor for
> now and only have a MediaStreamTrack(MediaStreamTrack) to make cloning
> consistent with MediaStream(MediaStream) (if we decide to go that way).
>
>> I would also suggest that AudioStreamTrack and VideoStreamTrack be
>> removed from the spec, since they now have no visible properties.
>
> That is my intention as well since removing the constructors from
> these types would leave nothing at all.
>
>> Replacing MediaStream.clone() with a MediaStream(MediaStream)
>> constructor doesn't matter to me - the difference seems to be syntax,
>> not semantics.
>
> So then the MediaStream(MediaStream) would clone the provided stream
> including its MediaStreamTracks.
>
> Should the MediaStream(sequence<MediaStreamTrack>) constructor clone
> the provided tracks or just add them?

I would say that it adds them, so that

s = MediaStream((track))

has the same result as

s = MediaStream()
s.AddTrack(track)

I think it would be confusing to have these two different.
>
> /Adam
>
>> On 11/04/2013 10:51 AM, Adam Bergkvist wrote:
>>> Hi
>>>
>>> In the current spec, we have the following APIs to create new
>>> instances of MediaStream and MediaStreamTrack:
>>>
>>> ------------
>>> MediaStream() constructor
>>>   - sequence<MediaStreamTrack>
>>>   - MediaStream (used to clone the given stream, but behavior changed
>>> (accidentally?) when we switched to explicit cloning of tracks)
>>>
>>> MediaStream.clone()
>>>
>>> AudioStreamTrack() constructor
>>>   - Constraints
>>>
>>> VideoStreamTrack() constructor
>>>   - Constraints
>>>
>>> MediaStreamTrack.clone()
>>> ------------
>>>
>>> I belive the API surface we expose for this functionality is a whole
>>> lot bigger than it would have to be. The Audio/VideoStreamTrack
>>> interfaces are empty now when getSourceIds() have become getDevices()
>>> on Navigator. I think we could get away with something like below:
>>>
>>> ------------
>>> MediaStream() constructor
>>>   - sequence<MediaStreamTrack> (add specified tracks to new stream)
>>>   - MediaStream (clone given stream; including tracks)
>>>
>>> MediaStreamTrack() constructor
>>>   - kind, Constraints (replaces constructors on derived types)
>>>   - MediaStreamTrack (clone given track)
>>> ------------
>>>
>>> /Adam
>>>
>>
>>
>


-- 
Surveillance is pervasive. Go Dark.
Received on Tuesday, 5 November 2013 17:04:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC