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

On 11/05/2012 04:20 PM, Adam Bergkvist wrote:
> On 2012-11-05 15:50, Harald Alvestrand wrote:
>> 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).
>
> I'm not really sure I understand. Do you wan't to keep separate lists 
> for audio and video tracks but have an allTracks() method on 
> MediaStream as well that aggregates the lists?
I see two possible approaches:

- Remove the MediaStreamTrack.
Having thought about this for an additional 5 minutes, this means:
  * New PeerConnection functions: getAllTracks, getTrack(id). 
getAudioTracks(), getVideoTracks() are PC-level utility functions that 
could be implemented on top of getAllTracks + a filtering operation.
  * addTrack(), removeTrack(), onaddtrack() handlers and onremovetrack() 
handlers need to be coded to actually consult the "kind" attribute of 
the objects they're handling to figure out if it's an audio or video 
track (if they need to). I don't think we need separate handlers, since 
the handling can be unified by an "if" test on the track kind.

- Keep the MediaStreamTrack.
In this case, track(id) and allTracks(id) need to be operators on the 
MediaStreamTrack.

Not sure which one is the right way forward.

Received on Monday, 5 November 2012 16:13:34 UTC