Using tracks instead of streams

This isn't rocket science, though it requires a degree of API-inversion.

Yes, I know that I'm breaking the rules with respect to use of
"attribute sequence<Foo>".  The rules are stupid.

partial interface RTCPeerConnection {
  // the set of tracks we are sending
  attribute sequence<Doohickey> sendTracks;
  // the set of tracks we are (maybe) receiving
  attribute sequence<Doohickey> receiveTracks;

  // add a track to the set of sending tracks
  Doohickey addSendTrack(MediaStreamTrack track);

  // fired when a remote track manifests
  attribute EventHandler? onremotetrack;
};

partial interface MediaStreamTrack {
  // the set of streams - i.e., synchronization contexts
  // that this track belongs to
  attribute sequence<MediaStream> streams;
};

interface DooHickey {
  readonly attribute MediaStreamTrack track;
  // and some other stuff
  attribute PriorityLevel priority;
  attribute unsigned long maxBitrate;
  // ellipsis
};

All the stream-related mechanisms are removed from RTCPeerConnection.
Nothing changes about the way that MSID and appID and those mechanisms
work.

The reason that MediaStreamTrack gets an accessor for the set of
streams that it belongs to is that if you are navigating this object
mesh starting from RTCPeerConnection, you wouldn't otherwise be able
to find the streams that exist.  Without that, worst case, the browser
wouldn't have a strong reference it could use to manage garbage
collection.

We are still talking about Doohickeys, so that interface has an ellipsis on it.

Received on Tuesday, 12 November 2013 06:45:21 UTC