RE: First draft available

>-----Original Message-----
>From: Anant Narayanan [mailto:anant@mozilla.com]
>Sent: Wednesday, November 30, 2011 10:18 AM
>To: Harald Alvestrand
>Cc: Robin Berjon; Stefan Håkansson LK; public-media-capture@w3.org
>Subject: Re: First draft available
>
>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.

I have a different philosophy here. I believe that hints are a good approach, but ultimately it's the user that must grant permission for a capability. I think that once the capability has been selected (which includes requesting and granting permission), then the explicit device configuration options can be provided to the developer.

To me, the LocalMediaStream represents both the set of current device configurations (for which it is acting as a stream, merging both audio/video capabilities) as well as the set of additional configurations that can be applied to the stream. Because it's local, its settings should be able to be changed, and those change requests should be able to affect the device for which the MediaStream is a conduit.

The current WebRTC drafts work in this manner (see the "enabled" property on the track objects). I propose that this be a model for adding additional configuration options to the local media streams (i.e., via their tracks, where a track is associated with a specific audio/video stream-providing device).

I also think this approach dovetails nicely with recent HTML5 video tag changes. The HTMLMediaElement includes three collections: videoTracks, audioTracks, and textTracks for captions. These tracks types support subtle configuration options that allow for audio track blending and video track switching. These interfaces could be extended with additional audio/video-specific capabilities for our purposes.

-Travis

Received on Wednesday, 30 November 2011 18:38:37 UTC