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

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