Re: Why ignoring unknown mandatory constraints is not stupid

On 11/15/13 5:58 AM, Harald Alvestrand wrote:
> The JS programmer says "I want a 3D camera. If I can't get a 3D 
> camera, I don't want any camera".
>
> Firefox 28 says "I have no idea whether this is a 3D camera or not. 
> I'll pass it up just in case it's usable."
>
> I don't see how this can be constructed as acting in accordance with 
> the programmer's wishes.

Because he CAN get a 3D camera some of the time. There will be times 
when the other constraints find the 3D camera, or where the 3D camera is 
the only camera, and in those cases, he would have gotten it if we 
didn't stand in the way. How can blocking it be in accordance with his 
wishes for a 3D camera?

By blocking the unknown you provide an invariant to the webapp, I 
appreciate that. But is that invariant more important than the false 
negative?

There's a cost to false negatives, directly to users and only indirectly 
to programmers. Does making sure nothing works until the browser is 
updated trump that?

If I already possess the camera that the webapp needs, it should just 
work. You're telling me I have to wait 4 months for a new browser that 
can let the app "recognize" my camera automatically instead of me 
picking it manually from a list? Isn't that a failure to operate for 4 
months? I would rather sacrifice the browser's ability to pinpoint a new 
capability automatically for 4 months than sacrifice my ability to use 
the camera for 4 months.

(Btw, constraints are camera pickers, not tech-enablers. Not every 
constraint is going to require dual-video-stream updates to 
PeerConnection, so 3D is an unusual example, but I'm sticking with it)

> If he was willing to accept a camera that was not a 3D camera, he 
> would not have specified a mandatory constraint.

It is mandatory that is broken, not optional. - I think it is reasonable 
to want browsers that can accurately pinpoint a camera by a new 
constraint, to do so ASAP, without the cost of having my app fail on 
browsers that can't do it yet.

Are you saying everyone should use optional for all new constraints to 
avoid this problem? For how long? When is it safe to use them as 
mandatory then?

Lastly, only programmers who know to care about false negatives will 
know to use optional, so a lot of them will use mandatory and things 
wont work for their users for a while, which will be correct for the 
subset that don't have this camera, at the cost of those that do. This 
is the footgun.

> Mandatory constraints guarantee that the resulting object is something 
> that satisfies the constraints.
>
> If they don't give such a guarantee, the JS script has to recheck all 
> the properties it depends on after it gets the device, just in case 
> the browser chose to ignore some of them.

We have very few constraints today, and somehow webapps aren't melting. 
I therefore claim this invariant is a red herring and that false 
negatives is the problem we should worry about.

> I don't see how this makes the JS programmer's life easier.

I think it's the users we need to worry about first.

getUserMedia() doesn't force you to accept a camera, it finds and grants 
access to the best camera available, as best it can (using known info or 
the user's help). When things are unknown, we have a choice: In one 
outcome the programmer has a candidate, access to query it and the 
user's system, and in the other outcome, no access, no candidate and an 
error. You wont even know if the error is legitimate (user doesn't have 
it) or if the browser has blocked you. That doesn't seem easier to me.

.: Jan-Ivar :.

Received on Saturday, 16 November 2013 06:08:03 UTC