Re: asynchrony for addStream w/ error/success callbacks

On Fri, Jan 10, 2014 at 8:28 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
> 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.

Why do you think it can't fail? Say I have a single hardware video encoder
and the programmer adds a second video stream. I'm not going to be
able to make a suitable offer.

I suppose you could argue that then I get a failure when I call "CreateOffer",
but that's a fairly odd notion of where failures should be reported, since
it leaves me in an almost unrecoverable state if I want to make any other
change to the PC.

-Ekr

Received on Friday, 10 January 2014 16:39:11 UTC