Re: Why ignoring unknown mandatory constraints is not stupid

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?

/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 00:12:17 UTC