Re: Constructors and cloning

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.

I would also suggest that AudioStreamTrack and VideoStreamTrack be
removed from the spec, since they now have no visible properties.

Replacing MediaStream.clone() with a MediaStream(MediaStream)
constructor doesn't matter to me - the difference seems to be syntax,
not semantics.

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 Monday, 4 November 2013 19:03:04 UTC