- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 21 Dec 2012 08:10:22 +0100
- To: public-media-capture@w3.org
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