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

Eric,

What is the extra risk/cost of moving to Promises before 1.0?

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

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