Re: PROPOSAL: New signature for getUserMedia and callbacks

On 03/30/2012 11:25 AM, Anant Narayanan wrote:
> What -- Change the signature of getUserMedia to:
>
> navigator.getUserMedia(options, callback);
>
> where option is a dictionary of type UserMediaOptions (currently
> video and audio are the two allowed keys, but easily extensible to
> include UserMediaConstraints/Hints), and callback is a single
> callback invoked in cases of either error or success.
>
> Why -- We've been wanting to steer away from using the two callback
> approach for a while now. There are multiple ways to do this. One
> proposal described using events, eliminating callbacks altogether.
> The usefulness of events in the case of getUserMedia was questioned
> (as it is not a DOM object), and the only useful property remaining
> would be that of multiple listeners.
>
> As we could not reach consensus on that (and events vs. callbacks is
> more of a style issue that I am willing to compromise on), I propose
> we use a node.js style callback to achieve the initial goal of moving
> away from the two callbacks.
>
> The main reason for not wanting to use two callbacks has been
> discussed before, the WebAPI design community in general has been
> moving away from this pattern.

Could you please provide some examples? Alignment with the rest of the 
Web API design community and using commonly recognized patterns is 
important IMO.

> In summary, we want error handling to
> be in the default path for developers, and two callbacks always makes
> the error callback be considered optional.  By using a single
> callback, even if the developer doesn't check the value of 'err' in
> their handler, an exception would have a reasonable stack trace (this
> is not true if the developer doesn't provide a failure callback and
> an error occurs).

Error handling will always be optional. If it's adding an extra 
callback, registering an error event listener, or adding an else 
statement to an "if (stream)..." (or "if (!err)...) statement in the 
single callback case.

Regarding exceptions and stack traces, this problem is actually 
introduced with the single callback solution since the MediaStream 
object may be valid or undefined. The stream argument is always valid if 
the successCallback is triggered in the two callback approach.

This is an interesting discussion since error handling will become more 
crucial when constraints are introduced. There's a higher risk that 
requests can't be met which will result in failed requests.

/Adam

Received on Thursday, 5 April 2012 14:29:48 UTC