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

On 11/05/2012 03:45 PM, Adam Bergkvist wrote:
> 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 <adam.bergkvist@ericsson.com>
>>> 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.
Oh - I thought we were already agreed to kill the MediaStreamTrackList 
object, since it's "only" a decorated array; I'd forgotten that the 
events were fired on the tracklist.

If we want to keep it, I think we should only have track(id) and 
allTracks() operations on it.
(which also makes the story about "what do we do for a third kind of 
content" that Cullen asks about once in a while a bit easier).

               Harald

Received on Monday, 5 November 2012 14:51:23 UTC