Re: asynchrony for addStream w/ error/success callbacks

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.

>
> I'm not sure if local streams trigger onaddstream/onremovestream, I
> don't think so, so I'd propose that we change the signatures of these
> methods to:
>
>   void addStream(MediaStream s, optional VoidFunction successCallback,
> optional RTCPeerConnectionErrorCallback failureCallback);
>   void removeStream(MediaStream s, optional VoidFunction successCallback);
>
> In case you were wondering, remove should not be allowed to fail...
>
> I think that optional is OK here.  That should help with backward
> compat, and these aren't really critical, since you can test for
> success/failure by probing.  Plus, onnegotiationneeded tends to fire
> if you do anything with the streams set.
>
>

Received on Friday, 10 January 2014 09:14:11 UTC