W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2012

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Mon, 5 Nov 2012 16:20:34 +0100
Message-ID: <5097D942.6050006@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: public-webrtc@w3.org
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?

/Adam
Received on Monday, 5 November 2012 15:21:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 November 2012 15:21:00 GMT