Re: Why ignoring unknown mandatory constraints is not stupid

On Sun, Nov 17, 2013 at 1:15 PM, Adam Roach <adam@nostrum.com> wrote:

> On 11/16/13 04:50, Harald Alvestrand wrote:
>
>> Because a mandatory constraint saying "3D camera" means "I want a 3D
>> camera". If he was happy with getting a 3D camera some of the time, he
>> could have used an optional constraint; if he desired other properties
>> of the 3D camera, he could have selected on these other properties.
>>
>
> As Jan-Ivar conceded, "3D" is actually a pretty bad example here, since
> it's not just a property of the camera, but something that requires browser
> support. Some constraints will be like that; some will not.
>
> Let's re-cast the question in the form of "facing mode." I'm making a
> videochat application, and getting a camera that can't see the user when
> he's looking at the screen is nonsensical. So I have a mandatory constraint
> that the camera I'm getting has to face the user. So, let's imagine that we
> didn't have "facing mode" on day one. It's added as a constraint at some
> point in the future [1].
>
> Now, my application ends up running inside a browser that doesn't yet know
> what this mandatory "facing mode" constraint means.
>
> What do you think should happen?
>

It should fail.

Honestly, I'm having a lot of trouble even understanding this argument.
Let's say that instead we didn't offer any kind of automatic selection
API but we maintain the current Settings API, so somebody writes in
their app:


if (track.settings.facingMode !== 'user') {
   // fail
}

and doesn't check for undefined.

This would, as in your example, fail, if the user's browser didn't know
about the |facingMode| setting. Would you argue that we shouldn't
provide this information because someone might choose to default
to fail?

-Ekr


> /a
>
> ____
> [1] To fend off any assertions that this is contrived because we already
> thought of and added "facing mode," you can replace my example above with
> "thermal imaging application" and "infrared camera" if that helps clarify
> the situation.
>
>
>
>

Received on Monday, 18 November 2013 14:05:41 UTC