Re: asynchrony for addStream w/ error/success callbacks

On 1/10/14 6:22 PM, Eric Rescorla wrote:
> On Fri, Jan 10, 2014 at 3:16 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> On 1/10/14 5:07 PM, Adam Roach wrote:
>>> On 1/10/14 12:03, Jan-Ivar Bruaroey wrote:
>>>> The createOffer error callback. It's an add/remove cart and checkout
>>>> pattern.
>>>
>>> On every e-commerce site I've ever used, an attempt to add an out-of-stock
>>> item (or more of an item than they have in stock) will complain at that very
>>> moment, as opposed to waiting for an attempt to checkout.
>>
>> You have the item already, so you know you're not sold out. You don't learn
>> that when you add.
>>
>> But it appears my analogy is not helping. Have you ever filled in a
>> C-language struct or JS object and passed that to a call? Same thing.
> Except, you know, that it's not, since we're making a series of
> independent subroutine calls and the API has an opportunity to
> detect that it's not going to work, it just declines to tell us.

It does not have that opportunity, which is why you guys have to propose 
a change.

And it is the same, subroutine calls or not. An "argument-object" can 
have access methods, which are independent sub-routines:

   var msg = new Msg(a).SetB(b).SetC(c);
   var result = ExecuteMsg(msg);

Like RTCSessionDescription. PeerConnection itself can act as the 
argument object since only one createOffer is allowed at a time.

> -Ekr

.: Jan-Ivar :.