Re: [ACTION-59] Introduce lookup by id structures for streams and tracks.

On 2012-11-05 15:12, Harald Alvestrand wrote:
> On 11/05/2012 03:02 PM, Martin Thomson wrote:
>> On 5 November 2012 13:36, Adam Bergkvist <>
>> wrote:
>>> B) Keep the possibility to use indices for looping (but not guarantee
>>> the
>>> order)
>> This is my preference.  Anything that returns sequence<MediaStream> is
>> fine.
>> I've seen too many instances of problems arising from custom
>> interfaces to be happy with anything else.
>> If you want to aggressively prevent the sort of programming errors
>> that we discussed, randomize the order.  You'll excuse me if I think
>> that's just a little excessive.
> I like simplicity.
> I'd like to introduce three operators on a MediaStream:
> sequence<MediaStreamTrack> videoTracks()
> sequence<MediaStreamTrack> audioTracks()
> sequence<MediaStreamTrack> allTracks()
> Text would say that the sequence is guaranteed to contain all the tracks
> present at the time of the respective type, and that there are no
> guarantees on their order.
> Looping is then completely up to the application; if the app wants to
> sort them on id before looping, that's the application's business.

This would mean a rather big change. For example, we would have to move 
add(), remove(), onaddtrack, onremovetrack and so on from 
MediaStreamTrackList to the MediaStream object. We would also have to 
define separate events for additions of audio and video tracks to keep 
the same level of control as we have today.


Received on Monday, 5 November 2012 14:46:02 UTC