RE: Why ignoring unknown mandatory constraints is not stupid

What if we warn the app that there is an unsupported mandatory constraint?  It can then decide whether to give up or remove the constraint, prompt the user, and see what it gets.  

- Jim
P.S.  I agree with Jan-Ivar that the app should not be told about a known, failed mandatory constraint, since that leaks information without the user even being asked.  But information about unsupported mandatory constraints is really just info about the browser version, and that's already available.  

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Saturday, November 16, 2013 7:50 AM
To: Jan-Ivar Bruaroey; public-media-capture@w3.org
Subject: Re: Why ignoring unknown mandatory constraints is not stupid

On 11/16/2013 07:07 AM, Jan-Ivar Bruaroey wrote:
> 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?

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.

(For the particular case of 3D, it's highly unlikely that even if the camera had 3D hardware, a browser incapable of understanding 3D would be able to produce a 3D videostream. A 3D videostream is formatted differently from a 2D one - and it is usually not formatted as 2x 2D videostreams. Another thing I learned at MPEG).

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

Sure, if you want a specific camera, you should be able to select that camera, instantly and immediately. But there's no reason the browser should "help" you by letting you select the camera by means of constraints that the browser can't parse.

> (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?

Let's consider a scenario using the 3D example.

I have bought (assuming a future where there's actually a commercially viable marketplace for JS applicaitons) an application for 3D modelling based on a stereo camera input.

I have bought a 3D camera, connected it to my PC, and fire up the application in my browser-of-choice - which just happens to not support 3D.
The application starts, asks for a 3D camera, and the right camera turns on.
But it presents a flat picture, and the 3D app tells me I'm looking at a plane surface.

Who's at fault?

The application, for not verifying that the camera as accessed through this brower platform was capable of supporting 3D?
The browser, for ignoring a "3D mandatory" constraint?
Me, for not having upgraded my browser?

When an application is *absolutely dependent on a certain camera
property* in order to function correctly, it's reasonable to use a mandatory constraint.

In *all other cases*, I think using an optional constraint is better.

But I don't see the argument for removing the mandatory constraint, and I *absolutely* don't see the argument for keeping the mandatory constraint but making it "mandatory part of the time".




--
Surveillance is pervasive. Go Dark.

Received on Saturday, 16 November 2013 14:46:57 UTC