W3C home > Mailing lists > Public > public-media-capture@w3.org > September 2014

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

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Wed, 10 Sep 2014 15:12:42 -0400
Message-ID: <5410A2AA.300@mozilla.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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. 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.

.: Jan-Ivar :.
Received on Wednesday, 10 September 2014 19:13:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:30 UTC