Re: MediaStream Constructor

On 5/10/12 6:57 AM, Adam Bergkvist wrote:
> On 2012-05-10 13:32, Rich Tibbett wrote:
>>>
>>> [Constructor MediaStream(obj1, obj2, obj3, ..., objN)];
>>
>> This does limit the potential to extend the MediaStream constructor with
>> additional arguments later on (e.g. options). We should probably keep
>> that possibility open and instead specify the MediaStream constructor as
>> follows (which is also in line with the new Blob object constructor
>> proposal [1]):
>>
>> [Constructor, Constructor((MediaStream or MediaStreamTrackList)?[]
>> streams)]
>>
>> As a developer you could then do any of the following:
>>
>> var stream = new MediaStream();
>>
>> var stream = new MediaStream([mediaStram1, mediaTrackList1, ..., objN]);
>>
>> This also means that at some later point in time we could adopt an
>> options argument if or when we might need that:

You're right, it's always good to leave room for arguments we may add in 
the future, and even though we could do it in the old style 
(obj1...objN) with some Lua-style varargs trickery, it's cleaner to just 
put everything in an array as a single argument; at the expense of minor 
developer overhead.

> I like this idea in general. The current approach with separate lists
> for audio and video doesn't really make sense since it's easy to put a
> track in the correct list (i.e. audio or video). Perhaps we could even
> support all three objects as arguments "MediaStream or
> MediaStreamTrackList or MediaStreamTrack".

Great, any objections to adopting Rich's proposal to modify the 
MediaStream constructor? I'd add a tiny tweak to also allow raw 
MediaStreamTrack objects even if they're not in a list:

[Constructor, Constructor((MediaStream or MediaStreamTrack or 
MediaStreamTrackList)[]  objects)]

Just to cover the use-case where I want to combine a single track from 
one list with another, without having to create an entirely new list 
just to encapsulate that one track.

>> With MediaStreamTrackList as a live collection object we know to fire
>> events when user's call an explicit method (i.e. 'add'/'remove'
>> methods). Other parts of the web platform also use Collection objects
>> rather than Array objects if any non-standard behavior is to be attached
>> to an attribute.
>
> I agree with the second point you make about non-standard behaving
> lists. We might need to have such behavior since it's been suggested
> that adding a track to a list will increase the length by one, but
> removing a track will not affect the list length. The removed track will
> simply leave a "whole" in the list to not affect the indexes of the
> other tracks. I think we should keep MediaStreamTrackList, but it needs
> some more work. For example, apart from the special remove behavior, it
> would be convenient to know both how long the list is as well as how
> many tracks it contains (since those numbers may not be equal).

These are pretty good reasons to retain the MediaStreamTrackList object, 
I will rest my case.

>> We could certainly tighten up the definition of the MediaStreamTrackList
>> collection interface and I would be happy to take an action to propose
>> some text here.

Sounds great, thanks Rich!

-Anant

Received on Thursday, 10 May 2012 19:23:54 UTC