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

Re: asynchrony for addStream w/ error/success callbacks

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 10 Jan 2014 10:14:39 -0800
Message-ID: <CABcZeBMW93dN11Cs-xSsH5EG8CnB1TY69TUU+DwJ92ntqNX1QA@mail.gmail.com>
To: 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 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.


>
>>> 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.

-Ekr
Received on Friday, 10 January 2014 18:15:48 UTC

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