RE: The UNKNOWN mandatory constraint behavior is a footgun

I'm fine with this.  How about other people?  I thought we agreed on Thursday to make mandatory constraints harder to use, but it was very late at night.  I think it was Dom who suggested that some constraint should not be able to be made mandatory.  If we agree not to make mandatory constraints harder to use, and want to allow all constraints to be mandatory, while changing _only_ the behavior of unknown mandatory constraints, then what Jan-Ivar is proposing makes sense.

Two questions though:

1.        Do we want a different consent prompt to the user in the case where there is an unknown mandatory constraint?  If we do, then we have to figure out  how gUM can signal that information to the UA or app.

2.       How should an unknown mandatory constraint behave in applyConstraints()?  There is no user involved here.  (In the current draft, the failure callback will be called.)


-          Jim

From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
Sent: Thursday, November 14, 2013 5:11 PM
To: public-media-capture@w3.org
Subject: The UNKNOWN mandatory constraint behavior is a footgun

I realize I shot my message in the foot by not being more precise in my subject line earlier.

It is the dictated treatment of mandatory constraints *unknown to the UA* that I'm highlighting a problem with.

I 100% support the existing spec behavior of mandatory constraints for constraints that the browser implements, and I would hate to see us make them harder to use. If an app doesn't want to support a resolution, lets not make it harder for it to declare this.

I also don't think browsers should police constraints, taking control away from webapps over which ones can be declared as mandatory. Power to the webapp!

In other words, webapps should be free to discriminate, without having to deal with the "bug" that browsers blind to a new constraint type will fail 100% of the time, rather than grant access to the best available device based on the information it does understand (which may just work, either directly or with the user's help).

I urge you to re-read my suggestion below if this wasn't clear the first time.

Sorry for any confusion this caused,
.: Jan-Ivar :.
On 11/12/13 1:04 AM, Jan-Ivar Bruaroey wrote:
I've implemented a strict interpretation of the spec's mandatory constraint that treats unknown keys as unsupported, I've tried it, and I think it is wrong.

Scripts should just work, so you mustn't use 'mandatory' unless you also code up a fallback, yet we've made it the thing people try first (with its marginally preferable syntax).

With future constraints coming, 'mandatory' is an invite to fail on a subset of browsers, a honeypot for newbie webdevs who test only their favorite browser(s).

At the same time, 'mandatory' is a sucky api for asking what the browser supports, because you can't just ask, you have to be prepared to do.

So it is bad for simple devs who just want to do, and bad for advanced devs who just want to ask.

It also goes against webidl (maybe even against the web), requiring implementers to circumvent dictionaries, which, as Travis points out, disallow detection of unknown keys for this very reason (future-proofing).

---

Now, all this may be justified, if there were no other way.

But I think there is another way:

MINIMALLY:

  1.  Browsers must have a getCapabilities() query that returns which constraints it implements.
  2.  We clarify that mandatory constraints are webidl dictionaries, e.g. unknown keys are ignored.
  3.  Browsers must include in webidl only the keys they actually implement.

The simple dev (with no fallback) can now just do, and things work as well as possible. This is the best outcome for this person.

The advanced dev (with fallback) uses getCapabilites() and then uses gUM with 'mandatory' to narrow sources only by the constraints the browser supports, giving them the control needed to make intelligent fallbacks.

This works with webidl, and is webby.

IDEALLY:

  1.  I'd love to see us go further and adopt a constraint format without the now-confusing name 'mandatory', like my "dictionaries of decreasing preference" proposal http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.html

.: Jan-Ivar :.

--
.: Jan-Ivar :.