- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Fri, 10 Jan 2014 11:28:09 -0500
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 1/10/14 4:13 AM, Stefan Håkansson LK wrote: > On 2014-01-10 02:39, Martin Thomson wrote: >> Since we're required to enqueue all mutation operations on >> RTCPeerConnection, I'm surprised that addStream, which has an >> interdependency on createOffer/createAnswer, is synchronous. It's not >> in Firefox, which means that it's not possible to report errors >> effectively. > I'm not sure what errors there could be. To me addStream just adds a > MediaStream to the "local stream set"; that "local stream set" is what > is considered at next createOffer/Answer. > > Likewise I'm not sure why it would have to be asynchronous. The content > of the "local stream set" will only matter at createOffer/Answer, and I > think there should be a synchronous part of those operations (they are > underspecified currently) which says something like "let xxx be this > RTCPeerConnection Object's local stream set; queue a task to perform the > following steps; ...." - modeled from setLocal/Remote. > > I may be wrong... > >> I'd like to suggest that we consider making addStream and removeStream >> asynchronous like everything else. >> >> Also, I looked, but I can't see a concrete use for the constraints on >> addStream. The algorithm forgets to even mention these. > I agree to this. +1. Removing the open-ended settings argument (MediaConstraints) means addStream cannot fail and does not need callbacks. .: Jan-Ivar :.
Received on Friday, 10 January 2014 16:28:37 UTC