W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2013

RE: Why ignoring unknown mandatory constraints is not stupid

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Fri, 15 Nov 2013 14:34:27 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2811ED32B@GENSJZMBX03.msg.int.genesyslab.com>
  I take the argument to be the following:  The app really wants a 3D camera.  If the UA doesn't understand the constraint at all, is it better that it call the failure callback, saying "No there is no device that meets your constraints", or to let it return something that might be a 3D camera.  

Remember that the new proposal, which I support, is to avoid information leakage by not saying which constraint could not be satisfied in the failure case. 

I think that at the very least we need to handle the case of unknown mandatory constraints differently.  There's a difference between knowing something is not true, and not knowing whether it's true.  Furthermore, I think we may want to prompt the user differently in the presence of an unknown mandatory constraint.   In the case of known constraints, we're saying "The app wants this camera, do you give permission?".  In the other case, it's more "This camera may not be what the app needs.  Do you want to try anyway?".  

The presence of an unknown mandatory constraint should be signaled to the app somehow, so it knows to examine the device to see if it's usable.  There are various ways to do this.  

- Jim

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Friday, November 15, 2013 5:59 AM
To: public-media-capture@w3.org
Subject: Re: Why ignoring unknown mandatory constraints is not stupid

On 11/15/2013 01:31 AM, Jan-Ivar Bruaroey wrote:
> On 11/14/13 12:01 PM, Silvia Pfeiffer wrote:
>> On Thu, Nov 14, 2013 at 6:36 PM, Jan-Ivar Bruaroey <jib@mozilla.com>
>> wrote:
>>> B) getUserMedia({ optional: [{ 3D: true }]}, success, fail); ->
>>>                                                       Firefox 28: 
>>> something
>>>                                                       Firefox 29: 3D
>>> It's B, because the user wants this to work, and will try to pick 
>>> the right camera when his browser and/or camera driver are clueless.
>>> Reaction card (check one):
>>>    [  ] But he may pick the wrong thing!! Burn! 404!
>>>    [  ] Let him play. The goal is not to control, but to make the 
>>> experience work seamlessly or work.
>>> So why not:
>>> C) getUserMedia({ mandatory: { 3D: true } }, success, fail);->
>>>                                                       Firefox 28: 
>>> something
>>>                                                       Firefox 29: 3D
>>> Because Firefox 28 doesn't know it's NOT a 3D camera...
>> So your argument is: the browser doesn't understand the constraint, 
>> so should pass the camera through because it could potentially be the 
>> correct device.
> Yes, well said. Thanks for that.
> For example, if the new 3D camera also has an extremely high 
> resolution you want, then the width/height constraints you'd add 
> (mandatory or optional) increase the likelihood of finding this camera 
> even on a system with an old browser and multiple cameras.

I don't understand this argument at all.

The JS programmer says "I want a 3D camera. If I can't get a 3D camera, I don't want any camera".

Firefox 28 says "I have no idea whether this is a 3D camera or not. I'll pass it up just in case it's usable."

I don't see how this can be constructed as acting in accordance with the programmer's wishes. If he was willing to accept a camera that was not a 3D camera, he would not have specified a mandatory constraint.

Mandatory constraints guarantee that the resulting object is something that satisfies the constraints.

If they don't give such a guarantee, the JS script has to recheck all the properties it depends on after it gets the device, just in case the browser chose to ignore some of them.

I don't see how this makes the JS programmer's life easier.
Received on Friday, 15 November 2013 14:34:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC