Re: Early Holiday Present: Settings API version 6

On 12/25/2012 03:07 PM, Jim Barnett wrote:
>
> If we think of an enum as a type, can’t a platform extend our 
> definition by adding new values (as long as it respects the ones we’ve 
> defined)?  I’m just curious, not arguing for any particular design.
>
In this case, I don't think it is a WebIDL enum.

We might want to use some similar language to what I proposed in the 
latest stats proposal, where I used the WebIDL dictionary syntax as a 
documentation, but described the API in terms of function calls that did 
not use these dictionaries.

Note - WebIDL has partial interfaces, which I assume can be used for 
partial enums, but unlike ABNF, using them for extending an existing 
interface in a separate document is currently discouraged.


> -Jim
>
> *From:*Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Monday, December 24, 2012 9:41 PM
> *To:* Mandyam, Giridhar
> *Cc:* Cullen Jennings; Stefan Hakansson LK; public-media-capture@w3.org
> *Subject:* Re: Early Holiday Present: Settings API version 6
>
> I just started taking a good look at this latest version, but I'm 
> concerned about the
>
> use of enums for scalar quantities, since that permanently
>
> constrains the ability of implementations to support values we didn't
>
> anticipate. A good example here is PhotoIsoModeEnum. It's fairly common
>
> to see digital cameras with ISO values other than these. For instance,
>
> I'm looking at a Canon Rebel XP1 which has 100, 200, 400, 800, and 1600.
>
> I suspect that Cullen's objection to white balance may be of a similar
>
> form.
>
> -Ekr
>
> On Mon, Dec 24, 2012 at 3:04 PM, Mandyam, Giridhar 
> <mandyam@quicinc.com <mailto:mandyam@quicinc.com>> wrote:
>
> Hi Cullen,
>
>
> > As just one example, I will encourage people that have worked with 
> video white balance to check out the white balance setting.
>
> Don't think Travis is to blame for that one - I proposed it in Camera 
> Settings, see 
> http://gmandyam.github.com/media-capture/#whitebalancemodeenum.  This 
> is consistent with what our drivers currently support in our chipset, 
> and with native API's such as Android (see 
> http://developer.android.com/reference/android/hardware/Camera.Parameters.html). 
>  But is your concern more about SW implementations of such features 
> when they aren't available natively?
>
>
> > seem to go against many of the decisions we already made about 
> constraints
>
> Can you be more specific?  I think this is consistent with what has 
> been discussed for the past 6 months.
>
> -Giri
>
>
> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@iii.ca <mailto:fluffy@iii.ca>]
> Sent: Monday, December 24, 2012 6:04 AM
> To: Stefan Hakansson LK
>
> Cc: public-media-capture@w3.org <mailto:public-media-capture@w3.org>
> Subject: 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 
> <mailto: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 
> <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 <mailto: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/001
> >>> 8.html
> >
>
>