- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Thu, 20 Dec 2012 19:33:25 +0000
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: Jim Barnett <Jim.Barnett@genesyslab.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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? > -----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 Thursday, 20 December 2012 19:34:34 UTC