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

On 2012-11-05 17:12, Harald Alvestrand wrote:
> 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.

Now I'm even more confused. You don't really want to remove 
MediaStreamTrack right? Previous mails hints that it's 
MediaStreamTrackList you mean, but the bullet about new methods on 
PeerConnection make me believe it's MediaStream you want to remove.

As long as we have MediaStream, I think that track-level operations 
should be on MediaStream rather than on PeerConnection. We need those in 
the local only case as well.

I think the object hierarchy we have today works. PeerConnection works 
with MediaStream objects and MediaStream together with 
MediaStreamTrackList handles the track level operations.

/Adam

Received on Tuesday, 6 November 2012 10:07:10 UTC