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

Re: asynchrony for addStream w/ error/success callbacks

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Fri, 10 Jan 2014 13:03:22 -0500
Message-ID: <52D035EA.4080805@mozilla.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: 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 12:09 PM, Eric Rescorla wrote:
> On Fri, Jan 10, 2014 at 9:04 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> 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.
> And how am I to discover what went wrong? What a baffling API semantic.

The createOffer error callback. It's an add/remove cart and checkout 
pattern.

I'm just describing my understanding of the current API: We have 
add/remove methods that cannot fail and a createOffer method (aka "do 
it") that can.

The onnegotiationneeded event on stable seems to corroborate this (like 
how 1-click adds to an already processed order at a famous retail site, 
to stick with the checkout analogy).

Said differently, if there was an intuitive way to express "add these 
and remove these other streams" as an argument to createOffer itself 
then we probably wouldn't have the methods at all.

If others interpret it differently, feel free to correct me.

>> 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.
> Huh? The right thing here is simply to have AddStream() fail, which doesn't
> leave you in this state at all.

Well, if it worked that way, then in your hardware-encoders-are-limited 
example, a client would have to be careful to remove any old stream from 
a stable stream FIRST before adding a new one, and not in any other 
order. There are some advantages to validating at the end, because you 
avoid the "don't step on any temporally invalid states landmine" dance.

You also have two points of failure that aren't obviously distinct IMHO, 
which means which failures are handled where may depend on 
implementation. Worse, if we decree that certain validation must happen 
in addStream, it may cause "bake twice" dilemmas. Having createOffer be 
the lone authority seems simpler to me.

> -Ekr

.: Jan-Ivar :.
Received on Friday, 10 January 2014 18:03:50 UTC

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