Re: First draft available

Hi Robin,

thanks for the really quick feedback. Some responses in line.

Stefan


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.
Right!
>
> 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?
Agree, the title was not at all thought about. We wanted to get the ball 
rolling.
>
> getUserMedia() uses the success/error callback approach, which is
> increasingly disliked. 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();
>
> Or the Node-style compound callback:
>
> navigator.getUserMedia(options, function (err, stream) {...});
>
> I personally have a preference for the latter, but that is naturally
> up for discussion.
This is a good discussion to have on this list I think!
>
> 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.
Basically there was not that much thinking. LocalStream inherits from 
MediaStream, so we figured that cutting this way was cleaner (or at 
least simpler when cutting / pasting from the webrtc document....)
>
> 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.
I agree, this must be addressed.
>

Received on Wednesday, 30 November 2011 14:22:53 UTC