Re: Early Holiday Present: Settings API version 6

Definitely my email requires me to send some more detail. I'll start some separate threads on it. 

On Dec 26, 2012, at 11:49 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:

> On 2012-12-24 15:03, Cullen Jennings wrote:
>> 
>> 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.
> 
> (Speaking as an individual) Cullen, would you care to elaborate a bit more? I certainly would have liked to see more feedback from implementors (and hopefully we will get that now) but so far there has been no signals that this is hard to implement. And in what way is it overly constrained and hard to extend?
> 
>> 
>> 2) seem to go against many of the decisions we already made about
>> constraints.
> 
> Again, some elaboration would be nice. When I read the proposal I get the impression that it is well aligned to how we have been using constraints so far. You can use constraints when changing some settings in the same way as they have been proposed to be used with getUserMedia before if I understand correctly.
> 
>> 
>> 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 Wednesday, 2 January 2013 21:03:03 UTC