- From: Anant Narayanan <anant@mozilla.com>
- Date: Wed, 30 Nov 2011 10:17:47 -0800
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Robin Berjon <robin@berjon.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, public-media-capture@w3.org
On Nov 30, 2011, at 8:31 AM, Harald Alvestrand wrote:
> On 11/30/2011 12:38 PM, Robin Berjon wrote:
>> Why is the title "getusermedia" when the method is getUserMedia? Perhaps a simpler, shorter title would work better. I don't want to bikeshed and think the editors should make the call, but maybe Media Capture API, or Local Media Capture API?
>>
>> getUserMedia() uses the success/error callback approach, which is increasingly disliked.
> By whom?
>
> This is the first time I've heard this comment, and the function has already been implemented in Chrome/Webkit, Firefox, Opera and Ericsson's Webkit-based experiment; I would have expected someone to comment on the style before now if the sentiment is widespread.
This particular comment has been brought up before in the WebRTC mailing list (ref: http://lists.w3.org/Archives/Public/public-webrtc/2011Oct/0002.html second point). I agree that the current callback mechanism is not very elegant. Both the event handler and node.js style callback are suitable replacements.
>> Or the Node-style compound callback:
>>
>> navigator.getUserMedia(options, function (err, stream) {...});
> As far as I can tell, this is completely equivalent to the success/error callback, except that you have written the callback as an anonymous function and put the job of distinguishing between success and callback within the function. What is the advantage of this approach?
The function doesn't have to be anonymous. The main advantage of this approach is that there is only one callback that handles both success and failure, instead of two.
> Device controls in general have not been addressed. At the last WEBRTC meeting, the suggestion was that device control was natural to do with "hints" (such as "resolution=bestPossible") on getUserMedia, but that interface hasn't been described yet.
>
> What's the current thinking on this subject for the declarative interface?
I would very much prefer to have a hints-style approach for both the declarative and programmatic interfaces. Data leakage aside, it is nearly impossible for the user agent to guarantee that it can provide whatever an application asks for, and 90% of the applications will want to continue to function even if they didn't get the full set of things they asked for.
-Anant
Received on Wednesday, 30 November 2011 18:18:44 UTC