Re: Why ignoring unknown mandatory constraints is not stupid

Jim,

Why do we need mandatory constraints at all? We can simplify the model 
by passing a list of priority-ordered constraints and let the app handle 
failure however it sees fit. This would simplify the model both for the 
vendor and for the application developer.

Gili

On 14/11/2013 4:12 PM, Jim Barnett wrote:
> OK, I agree that we're talking only about unknown mandatory constraints.  Another option, which changes the semantics of mandatory constraints even less, is along the lines I mentioned last night - a separate API call to queue a mandatory constraint, which is applied only when you make the existing API call (gUM or applyConstraints) with a list of optional constraints.  The call to queue a mandatory constraint will return an error if a) the constraint specified is not allowed to be mandatory (we discussed this possibility on the call) or b) the UA doesn't recognize the constraint.   The app now has the choice of not asking for permission at all, or of asking with the remaining constraints and seeing what it gets.
>
> Having the UA refuse to enforce an unknown constraint seems reasonable to me: since it doesn't know what the constraint means, it can't tell whether a device supports it or not.
>
> Pulling the mandatory constraints out into a separate call also has the advantage of encouraging the developer to use optional constraints:  he's going to have to call gUM with a bunch of optional constraints anyway, so the simplest thing to do is to make all constraints optional.
>
> - Jim
>
> -----Original Message-----
> From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
> Sent: Thursday, November 14, 2013 3:12 PM
> To: Jim Barnett; public-media-capture@w3.org
> Subject: Re: Why ignoring unknown mandatory constraints is not stupid
>
> On 11/14/13 11:54 AM, Jim Barnett wrote:
>> I think that there may be a slightly different way to look at this that won't give the jack-booted mandatory police (of which I am one)  heartburn:  the user makes the final decision and can override mandatory constraints, though he will be warned that he is doing so.
> Careful, for mandatory constraints *known and supported by the browser*, we said the user should NOT be able to override. I'm not challenging that, in fact I'm a proponent. agree with that! I also have enough heat here already. :-)
>
> I'm going to consider the rest of what you're saying as being solely about *unknown* mandatory constraints, which is where the problems I'm highlighting are.
>
>>     If no camera satisfies the mandatory constraints, the permission
>> window still pops up saying "None of your cameras meet the app's
>> requirements, would you like to try anyway?" or something like that.
>> If he agrees, the camera would then be returned to the app with some
>> signal that it doesn't meet the mandatory requirements (there's no
>> information leakage there, because the app now has full access to the
>> camera.)
> Exactly, and the signal for this is already present:
>
>       result->getVideoTracks()[0].getCapabilities().hasOwnProperty("3D")
>
> This works even for unknown constrainable properties, because the JS passes in a string here and the Capabilities webidl-dictionary will only contain 3D if the browser supports it AND the camera does.
>
> ---
>
> Also, thank you for highlighting an important point, that getUserMedia() is about access. If you want control, why turn down access? If you care about control, access is key. Once you have access, you're in a way better position than you were before to determine if you have what you need. - Go ahead, call getMediaDevices() and snoop for bleeding edge device names if you want to. There's also zero obligation here.
>
> The only thing that would be bad here, in my mind, is if getUserMedia() returned the wrong camera on the first try *when there was a right one to be had*, because re-asking is bad UX.
>
> For constraints known to the browser, I'm fine with the browser limiting user-choice (even though as I think about it, there may be a similar issue lurking with devices that don't understand a particular constraint, e.g. if the device doesn't know facingMode at all, then we may not be able to deduce which way it faces, even though clearly it must be facing one way or the other. Is always excluding it without user-override, always the right choice, even when no better choices were found? I need to think about that, though I'm confident we can tune the algorithm here if we need to.)
>
> For constraints NOT known to the browser, what I object to is trusting the browser of a specific vintage to know anything at all. Leaving aside my inherent skepticism about a webapp picking the right camera over the user on a sunny day, can we all agree that taking ConstraintNotSatisfiedError at face value for unknown keys leads only to failure? - Let the user fix this. They want it to work too.
>    
>
>> I don't view this as changing the nature of mandatory constraints, so
>> much as stating that the user always has the final say. The app can
>> still examine the constraints that failed and pop up a "sorry you need
>> a better camera" message.
> I agree with the sentiment that we're tweaking here, not "starting over", although I object to the user having final say when the browser knows better. We just need to appreciate the limits of what the browser can understand. Unknown constraints is not one of those things. - I'll wager we're not the first working group to have arrived at this.
>
> .: Jan-Ivar :.
>
>
>> - Jim
>>
>> -----Original Message-----
>> From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
>> Sent: Thursday, November 14, 2013 5:36 AM
>> To: public-media-capture@w3.org
>> Subject: Why ignoring unknown mandatory constraints is not stupid
>>
>> Someone mentioned that constraints are about needs and wants. I love that, because it's as descriptive of the application as it is prescriptive of the browser and its user (unlike those other unilateral terms).
>>
>> It's getUserMedia(), not getBrowserMedia(). The browser negotiates between the app and the user, not the app and the machine.
>>
>> But enough hippie stuff...
>>
>> WHICH WAY GIVES YOU ACCESS TO THE USER'S NOSEBLEED5000 3D CAMERA MOST OFTEN?
>>
>> A) getUserMedia({ mandatory: { 3D: true } }, success, fail);-> Firefox
>> 28: ConstraintNotSatisfiedError
>> Firefox 29: 3D
>>
>> 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...
>>
>> C is better than B, because it wont list irrelevant cameras in Firefox 29.
>>
>> .: Jan-Ivar :.
>

Received on Friday, 15 November 2013 13:23:17 UTC