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:44:12 -0500
Message-ID: <52D03F7C.4040200@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 1:14 PM, 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.

Busted == baffling, or busted == wont work?

>>>> 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.
> This seems like exactly the pattern that practically every other resource
> allocation API I have ever seen uses.

Except as Stefan points out, nothing really happens/matters until 

> -Ekr

.: Jan-Ivar :.
Received on Friday, 10 January 2014 18:44:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:53 UTC