Re: asynchrony for addStream w/ error/success callbacks

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