Re: Early Holiday Present: Settings API version 6

On 12/20/2012 08:33 PM, Travis Leithead wrote:
> I think this is all great feedback. I'm not going to re-integrate
> this feedback into the v6 proposal, I'll just expect that this gets
> clarified in Media Capture and Streams when v6 is adopted in.
>
> How's that going by the way?

In the note sent a couple of days ago, we gave until the end of today 
(Dec 21st) for people to object to starting the integration. There has 
been no objection so far, so I expect the editors are preparing to get 
started!

Stefan

>
>> -----Original Message----- From: Adam Bergkvist
>> [mailto:adam.bergkvist@ericsson.com] Sent: Wednesday, December 19,
>> 2012 12:29 AM To: Martin Thomson Cc: Travis Leithead; Jim Barnett;
>> public-media-capture@w3.org Subject: Re: Early Holiday Present:
>> Settings API version 6
>>
>> On 2012-12-18 20:12, Martin Thomson wrote:
>>> I'm inclined to address this differently.  Either:
>>>
>>> 1. Provide a "file" device placeholder on all browsers (crappy
>>> user experience because now we get false positives when apps
>>> check to see if the user has devices) 2. Create a new device ID
>>> for files when the user opts to create the file, which to the app
>>> appears to be a new device that was "plugged in" in response to
>>> their request for a mic/camera.
>>>
>>
>> I like your idea with a selected file being treated as a device
>> that gets plugged in as a response to getUserMedia(). It might be
>> quite common user behavior to plug in new a device when the
>> preferred webcam doesn't show up in the list of available devices
>> (because it's in your bag on the floor). With this solution we have
>> the option to assign this particular file a unique id and let it
>> show up in getDeviceIds() as a "readonly" source from that point.
>>
>> This might satisfy both the cases where you don't want to show some
>> UI because the user doesn't have any connected devices (Mathew's
>> case from Lyon), but at the same it lets the user opt in with a
>> file for privacy reasons and it's gets treated as a newly connected
>> "real" (readonly) device.
>>
>>> I prefer the second, which is very much like your fourth, with
>>> one difference: getDeviceIds() still works.  Apps can't enumerate
>>> files (a good thing), but that's OK.  There are several up-sides
>>> over what you suggest): - apps can't request a specific file -
>>> apps can still see what "real" devices are present prior to
>>> requesting permission (necessary for some use cases) - users can
>>> choose a file if the app permits it, at which point we can decide
>>> how much to share with the app about that file
>>>
>>
>> The fact that users only can select a file if the app permits it
>> conflicts with the original idea with files as replacements for
>> devices for user-empowerment (as Tim nicely describes it in [1]).
>> I'm not saying that we can't relax that requirement, but we have to
>> be aware that were doing it.
>>
>> /Adam
>>
>>> I'm still in two minds as to whether there is one device ID for
>>> files altogether or whether there is a different device ID for
>>> each file. I'm leaning toward the former.
>>>
>>> I still believe that hiding device IDs until after consent is
>>> granted is overly cautious.  It prevents some application usage
>>> scenarios.
>>
>> [1]
>> http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/0018.html

Received on Friday, 21 December 2012 07:10:50 UTC