Re: First draft available

On 11/30/2011 12:38 PM, Robin Berjon wrote:
> Hi,
>
> On Nov 30, 2011, at 12:05 , Stefan Håkansson LK wrote:
>> to get started, a first Editor's draft (based on getUserMedia in the WebRTC 1.0 document) has been created:<http://dev.w3.org/2011/webrtc/editor/getusermedia.html>.
>>
>> The initial editors are Dan Burnett and Anant Narayanan.
> Excellent! Thanks for getting this ball rolling. Some quick notes follow (in no order whatsoever).
>
> We will need to sort out the boilerplate so that it matches joint IPR coverage. Not something we need to do now but we'll need to handle it before publication.
>
> 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.
>   I would suggest either returning an object on which handlers can be set:
>
> var um = navigator.getUserMedia(options);
> um.onsuccess = function (stream) { ... };
> um.onerror = function (err) { ... };
> um.start();
This, of course, raises the question of what the "um" would represent, 
whether it is a permanent object or something that can be thrown away 
once the request has been replied to.
> 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?

> I personally have a preference for the latter, but that is naturally up for discussion.
>
> Do we expect LocalMediaStream to remain outside of this spec? I don't have an opinion on this, I'm just curious about the thinking behind the cut.
Either we drag in all of MediaStream, or we leave all of it outside. If 
the people who want to remain outside the WEBRTC WG wish to comment 
heavily on MediaStream, it may (or may not) make sense to move it over; 
if they do not so wish, I think it should remain where it is.
> One issue that remains fully open is the capture of stills. A typical use case would be to acquire the video feed from a camera in order for it to serve as a viewfinder in the application, and then be able to trigger a still capture from the device. Note that frame-grabbing is not at all an option here since you will never get anywhere near the quality that the device can produce.
>
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?

Received on Wednesday, 30 November 2011 16:32:08 UTC