W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

RE: Early Holiday Present: Settings API version 6

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>
Message-ID: <9768D477C67135458BF978A45BCF9B3853AF945E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:13 UTC