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

Re: asynchrony for addStream w/ error/success callbacks

From: Adam Roach <abr@mozilla.com>
Date: Fri, 10 Jan 2014 15:37:06 -0600
Message-ID: <52D06802.3010504@mozilla.com>
To: Eric Rescorla <ekr@rtfm.com>, Jan-Ivar Bruaroey <jib@mozilla.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:14, Eric Rescorla wrote:
> On Fri, Jan 10, 2014 at 10:03 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> 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.
> Well, my point (and Martins and Adam's like a month ago) is that this
> is busted.

For the record, I agree with EKR, Martin, and even my earlier self.

I don't agree with the prospect that we should defer errors to some 
point significantly later than is necessary. I mean, if an application 
wants to do something like add eight video streams, up to the maximum 
that can currently succeed, then the semantics we're proposing would 
allow determination of that limit by adding eight streams and seeing if 
any of them fail.

What you're proposing is that developers would try to add eight, see 
that fail, and then either perform some kind of linear backoff or binary 
search to determine what the number of streams they can successfully add 
might be.

There's a pretty well worn design principle in protocol development that 
you don't combine lots of operations into a single command/response 
sequence unnecessarily, since it forces the operations need to succeed 
or fail atomically. This seems like a natural translation of that 
principle into API design.

Adam Roach
Principal Platform Engineer
+1 650 903 0800 x863
Received on Friday, 10 January 2014 21:37:34 UTC

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