Re: asynchrony for addStream w/ error/success callbacks

On 1/10/14 11:37 AM, Eric Rescorla wrote:
> 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.

Good point about it being odd, tough I disagree it would be 
unrecoverable, as addStream would presumably push streams to a temporary 
list that createOffer discards (or prunes) if it fails.

Should addStream(a), addStream(b), removeStream(a), createOffer() work? 
That would not be possible unless the validation was deferred (along 
with the rest of the actions) to createOffer.

As I interpret the negotiationneeded event here, I think 
addStream/removeStream are request-builders for createOffer.

> -Ekr

.: Jan-Ivar :.