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

On 11 Sep 2014 05:13, "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. The bug was not solved by tighter
argument checking.
>
> 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 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.

Promises is still a very new concept. I've not seen any very large
application written solely with promises. In fact, Java is dropping
promises and moving to callbacks. It's not proven that either is better.
I'd be happy to run with both for a while. Deprecation of any old style api
should go slowly over years and not suddenly. In short: I'd prefer we are
stuck with callback "forever" (ie. For likely the next decade).

Silvia.