W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: asynchrony for addStream w/ error/success callbacks

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 10 Jan 2014 09:13:45 +0000
To: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C436BFE@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC