"add" needs to enforce "kind" limitations

Since MediaStreamTrackList is agnostic to the "kind" (e.g., "video" or "audio") of MediaStreamTrack objects it holds, yet, two lists exist for each kind-the audioTracks versus videoTracks-the MediaStreamTrackList:add() API must be more restrictive in order to keep only MediaStreamTrack objects of kind=audio in the audioTracks list and video in other other.

I suggest adding another step to the "add" method's algorithm:
4.1          Let kind be the MediaStreamTrack object's internal kind attribute
4.2          If kind is "audio" and this MediaStreamTrackList corresponds to "videoTracks", then abort these steps.
4.3          If kind is "video" and this MediaStreamTrackList corresponds to the "audioTracks", then abort these steps.

The "corresponds to" bit is pretty hacky. Might make more sense to sub-type out the MediaStreamTrackList (e.g., MediaStreamAudioTrackList and MediaStreamVideoTrackList).

Received on Friday, 27 July 2012 23:45:37 UTC