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

> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> On 11/06/2012 11:06 AM, Adam Bergkvist wrote:
> > 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.
> >
> Argh, that came out completely tangled.
> 
> What I intended for the first option:
> 
> - Remove the MediaStreamTrackList.
> Having thought about this for an additional 5 minutes, this means:
>    * New MediaStream functions: getAllTracks, getTrack(id).
> getAudioTracks(), getVideoTracks() are MediaStream-level utility functions
> that could be implemented on top of getAllTracks + a filtering operation.
>    * addTrack(), removeTrack(), onaddtrack() handlers and onremovetrack()
> handlers need to be recoded 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.
> 
> I think you can actually implement the old MediaStreamTrackList as a polyfill
> on top of this, except that you can't implement stable indexes....

This model actually sounds great to me. It solves a number of other existing problems like having to auto-sort tracks into the right track-list bucket.

Received on Wednesday, 14 November 2012 21:21:12 UTC