- From: Cullen Jennings <fluffy@iii.ca>
- Date: Tue, 12 Nov 2013 15:26:13 +0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
yah, this looks good but not sure how receive side works to create the Doohickey
On Nov 12, 2013, at 2:44 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 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 07:26:33 UTC