RE: Why ignoring unknown mandatory constraints is not stupid

Yes, that's what I had in mind.  The error callback would get the name of the constraint involved if it was an unknown mandatory constraint, otherwise not (so the app would not find out the cause of failure if it was due to a known mandatory constraint or the user refusing to grant permission.)

- Jim

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

On 11/16/2013 03:46 PM, Jim Barnett wrote:
> 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.  

I think calling the error callback is a fine form of warning.
If the app is wiling to go into dialogue with the user about whether or not to remove the constraint, and then return to a new, less restricted getUserMedia, so much the better for the app. I don't see a reason to complicate the interface beyond that.


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


--
Surveillance is pervasive. Go Dark.

Received on Sunday, 17 November 2013 14:21:30 UTC