Re: [webrtc-pc] Change [[AssociatedMediaStreams]] to [[AssociatedMediaStreamIds]]

> Let sender have an [[AssociatedMediaStreamIds]] internal slot, representing a list of Ids of MediaStream objects that this sender is to be associated with.

Conceptually we have "`MediaStream` objects that this sender is associated with" and `MediaStream` IDs are _not unique_, so I think this relationship should be explicit rather than implicit, even if SDP only signals the IDs and implementation-wise IDs work.

I think this for three reasons, including symmetry between senders and receivers and usefulness of exposing streams.

1. If we were to do the same thing for receivers, i.e. have an `[[AssociatedRemoteMediaStreamIds]]` slot, because IDs are not unique and tracks are added to/removed from stream objects, implementing this would either be buggy or implicitly have an `[[AssociatedRemoteMediaStreams]]` slot, in which case `[[AssociatedRemoteMediaStreamIds]]` would add no value.

I would prefer to maintain the symmetry between "senders and streams" and "receivers and streams"; I think changing one of the cases to Ids just adds confusion. If a UA really want to get rid of references (which I question too) that can be an implementation detail, not advised by the spec.

2. Since legacy `getLocalStreams()` has to be implemented as "all streams of all active senders", and there is great usage of `getLocalStreams()` and `getRemoteStreams()`, this shows that there is an application need for the stream references. You could force the application to keep track of these references instead, but this seems unnecessary, I would rather expose a `readonly  sequence<MediaStream> attribute streams` to both senders and receivers. This would make it possible to shim `getLocalStreams()` and `getRemoteStreams()`, which would take us one step closer to deprecating these APIs in the UA implementation.

Even if we don't do 2. I don't think this change adds value in and of itself, just confusion. I think it was motivated by [this](

> What I think is true however, is that we probably don't need to keep a reference to the streams themselves, just their ids. Since keeping a stream open has side-effects (local camera staying on) that seems like an improvement (remember what's being sent may come from an entirely different stream).

Which brings me to my third point.

3. If a stream is associated with a sender it is in use by the PC. The stream should not be garbage collected, the camera should not be closed. With this change, what happens if the application does not have a reference to the stream after attaching it to the PC? Camera stops and stream is GC'd? This could happen midst conference.

I disapprove of this change. I don't like implicit relationships.

GitHub Notification of comment by henbos
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 27 February 2018 10:51:19 UTC