Re: Early Holiday Present: Settings API version 6

I just read this draft now 

1) it looks problematic in many ways - glad to discuss next time we have some face to face time. Many of the things seem a) very hard to implement in a browser b) way overly constrained and hard to extent in the future c) not lined up with how existing software process video. As just one example, I will encourage people that have worked with video white balance to check out the white balance setting. 

2) seem to go against many of the decisions we already made about constraints. 

I strongly object to putting it in the editor draft. I also talked to someone at mozilla and it seemed like they had not been following it. I think we need agreement to put this is in - right now what I misty see is very few people are following it. 


PS - sorry this is from my IETF email address but my Cisco email seems down for holidays ….


On Dec 21, 2012, at 12:10 AM, Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> wrote:

> 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 Monday, 24 December 2012 14:04:12 UTC