Re: Promises (Re: New Editor's Draft of MediaStream Image Capture)

On Wed, Sep 10, 2014 at 3:20 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Eric,
>
> What is the extra risk/cost of moving to Promises before 1.0?
>
> That wasn't the only argument. We have existing code and the marginal
benefit
of Promises seems, well, marginal.



> Back in the day, the only argument given against Promises was that they
> weren't ready/established yet.
>


> Now that they are ready the argument we're given is it's too late to add
> them. I want to put things in perspective here: we're talking about a
> single API method. If you feel this way about gUM then I want to imagine
> what it would take to add Promises to the rest of the API (for which it is
> not "too late" yet).
>

I think it's too late for the rest of the API as well.

-Ekr

We've already established that moving to them post 1.0 will incur the cost
> of having to support the older API. The benefit is reduced risk (whatever
> that risk might be). I would like to hear a more concrete risk analysis for
> either approach.
>
> Gili
>
>
> On 10/09/2014 5:46 PM, Eric Rescorla wrote:
>
> On Wed, Sep 10, 2014 at 12:12 PM, Jan-Ivar Bruaroey <jib@mozilla.com>
> wrote:
>
>>  On 9/10/14 11:25 AM, Eric Rescorla wrote:
>>
>> On Wed, Sep 10, 2014 at 7:07 AM, Jan-Ivar Bruaroey <jib@mozilla.com>
>> wrote:
>>
>>> Except there's zero compatibility problems with overloading the existing
>>> function as well, since it returns void, and callback args can be made
>>> optional.
>>>
>>
>>  This seems like an especially bad idea. We've already had one Firefox
>> bug this
>> month that could have been averted by tighter argument checking.
>>
>>
>> The firefox bug was caused by not having tests for a common use-case that
>> still exists in the wild thanks to the spec changing - omitting callbacks
>> to setRemoteDescription - People omit callbacks because a) it works, b)
>> they don't see the need to check for failures at every turn, and c) because
>> adding callbacks is laborious. Promises address these problems: omitted
>> callbacks don't break propagation.
>>
>
>  Sort of. The reason we required failure callbacks is we wanted
> people to check for errors. Promises just make it optional to
> check for success or failure.
>
>
>
>> The bug was not solved by tighter argument checking.
>>
>
>  Adding tighter argument checking would have.
>
>
>
>>  Whether we overload the name or not doesn't change the size of the API
>> surface, so I don't see that there'd be more bugs one way or the other.
>>
>
>  I guess we're going to have to agree to disagree on this.
>
>     I don't see the problem with defining a new API point that uses
>> promises.
>> This also has the advantage that you could do it later.
>>
>>
>>  Sure, but then we're also stuck with callbacks forever
>>
>
>  This hardly seems like the worst thing in the universe.
>
>  -Ekr
>
>
>>
>> .: Jan-Ivar :.
>>
>>
>
>