Re: Why ignoring unknown mandatory constraints is not stupid

On 11/17/2013 10:15 PM, Adam Roach 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?

If you as an application designer have decided that your application
should not work with detached cameras that the user can turn (where the
browser will likely NEVER know which way the camera is facing), I think
your application should get exactly what it wants: No camera.

With mandatory constraints, I have to assume that the apps developer has
made a deliberate choice to not support the cases where he can't be
assured that the property is satisfied.

Again, I don't see why this choice (which makes a lot of sense in
several cases) is so dangerous that the developer should be protected
against making it.


>
> /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.

Done: If I'm doing an application whose only purpose is analyzing houses
for isolation hotspots, getting a non-thermal camera will just mean that
I have to make code paths to deal with "this is a camera, but the data
I'm getting from it is completely nonsensical". I don't want to spend
time doing that.

Most likely, I'll even insist on getting a camera with an ISO XXXX heat
profile calibration, since I can't trust that any IR camera will do -
and if I am selling my program as part of an ISO 27000-certified
inspection procedure, getting an uncalibrated sensor is very very bad
news indeed.
Surveillance is pervasive. Go Dark.

Received on Monday, 18 November 2013 04:40:51 UTC