Re: Why ignoring unknown mandatory constraints is not stupid

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.

> The problem with that argument is: it's a new constraint because it
> enables new features that were not before available. For example: a 3D
> camera may provide two video streams requiring two video elements for
> display, so the app dev might have required 3D as mandatory because he
> is expecting two streams to connect. Since the browser is not
> supporting the 3D camera, it may provide only 1 stream or potentially
> none.
>
> Basically, you're just delaying the failure to a later time where the
> app dev relies on a certain functionality.
>
> If he/she didn't rely on this functionality, he/she wouldn't have
> specified it as mandatory.

It sounds like you're implicitly asking the browser whether it supports dual-video-streaming, using a constraint. You should be able to ask your browser directly about this inherent detail, without having to push for gUM-permissions, as getting this information does not involve accessing the cameras at all.

You're requiring the user to have two things here, a browser with dual-video-support, and the camera. Some users may have one and not the other. Cameras often come loaded with other features, so perhaps it has a red/blue-glasses mode that works with any browser.

I don't think we should overload the constraint in this manner, because there may be legitimate reasons to pick this camera, even on a browser that doesn't have dual-video support.

>>> C is better than B, because it wont list irrelevant cameras in Firefox 29.
>> In B the browser would not need to list the cameras either.

C doesn't return false positives in the Firefox 29 case, which is generally desirable (why we have mandatory).

>> Silvia.

.: Jan-Ivar :.

Received on Friday, 15 November 2013 00:32:26 UTC