- From: <bugzilla@jessica.w3.org>
- Date: Mon, 02 Sep 2013 15:24:14 +0000
- To: public-media-capture@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23128 Bug ID: 23128 Summary: Add an explicit "get access to media" call Classification: Unclassified Product: WebRTC Working Group Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Media Capture and Streams Assignee: public-media-capture@w3.org Reporter: harald@alvestrand.no CC: public-media-capture@w3.org One of the problems with the current method of getting access to media is that it occurs as a side effect of a call done for other purposes (GetUserMedia). The parameters for this aren't ideal to determine the full range of permissions that a page would want - for instance, a page might first open a video device, and later open an audio device separately; in our current models, that would give 2 permissions prompts. Instead of doing it this way, we could make an explicit call: void GetMediaPermissions(Permissions permissions, successCallback, errorCallback) Permissions = enum( "videoInputDevices", "audioInputDevices", // and maybe extend this to "deviceEnumeration", "screenCapture", "windowCapture", .... ) The UA could then use the list of permissions requested to construct an appropriate UI element for asking permission from the user (or use a stored permissions model to grant access immediately, if that's the Right Thing). In any case, all programs that know what class of permissions they want can get those permissions with one call, one prompt, no matter what they do later. For backwards compatibility, getUserMedia would be documented to have an implicit call to GetMediaPermissions "behind the curtains". An earlier attempt was http://dev.w3.org/2009/dap/perms/FeaturePermissions.html - an important difference between that and this proposal is that this proposal explicitly states that one can ask for a set of features, not just one at a time, and that user prompts (and therefore reasonably long delays) are to be expected. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
Received on Monday, 2 September 2013 15:24:15 UTC