RE: Why ignoring unknown mandatory constraints is not stupid

For getSupportedConstraints, we should think about the details a bit - there may be many Constrainable classes that the UA knows about (MediaRecorder, etc.), so this function would have to return values for all of them.  In many cases, this won't be useful because capabilities() gives you the same information once you have an instance of the class, and getting an instance is normally not an issue.  It's only with Tracks and gUM that you want to find out what constraints are supported before you get an instance.

I agree that the success callback shouldn't be called in the case of an unknown mandatory constraint, but failing and signaling an error that includes the name of the unknown constraint would give the app full control of the situation.  It could give up, or remove the constraint and try again.  A knowledgeable developer should know which constraints are likely to be unknown and whether there is a chance of doing something useful in that case.  

We've done enough thinking about mandatory constraints that I don't see any reason not to include them.  Furthermore, if we leave them out, what does our syntax look like?  Do we pass a constraints structure containing only the 'optional' item?  That will look strange.  Developers will expect to simply pass a list of constraints.  But if we let them do that, their apps will break when we introduce mandatory constraints.  

- Jim

-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Tuesday, November 19, 2013 4:30 AM
To: Harald Alvestrand; public-media-capture@w3.org
Subject: Re: Why ignoring unknown mandatory constraints is not stupid

On 18/11/13 21:57, Harald Alvestrand wrote:
> On 11/18/2013 09:36 PM, Jan-Ivar Bruaroey wrote:
>> On 11/17/13 11:40 PM, Harald Alvestrand wrote:
>>> 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.
>>
>> I'm not saying you have to. One line is all it takes:
>>
>>    if (!browser.getSupportedConstraints().hasOwnProperty("thermal"))
>> return false;
>>
>> This is an app decision.
>
> By the same token, why should this developer (who write apps for 
> thermal cameras only) be the one to do that, and not the one who can 
> live with a visible-light camera when his application is written for a thermal?
>
> The getSupportedConstraints() actually makes things a lot easier when 
> dealing with constraints that the browser may or may not know, no 
> matter whether the WG eventually agrees with me or with Jan-Ivar.
>
> But I think I'll stop posting on this subject. Let's hear from others.

Well, as you asked for it:

On the topic of gUM failing or not on unknown mandatory constraints ===================================================================
I come to the same conclusion as Harald. If we take the example of "zoom" (which seems the one just outside mandatory-to-support according to slide 24 in
http://www.w3.org/wiki/images/f/fd/Constraints20130406.pdf): Assume my app for some reason must be able to control zoom (so it puts it as a mandatory constraint for gUM). If the browser doesn't understand "zoom", I am not helped by a success CB because the browser can't control the zoom - and that was a mandatory requirement for me.

On getSupportedConstraints
==========================
This is a really good proposal I think, we should introduce (something
like) this.

On Mandatory constraints in general
===================================
I like the expressiveness of them, but I have two issues:
1. We do introduce some fingerprinting possibilities (20 questions) 2. I keep hearing that some OS's (that has a non negligible market
share) just answer "yes, I can do that".
Would it make sense to go with only optional constraints for the first version?



>
>

Received on Tuesday, 19 November 2013 14:00:20 UTC