Proposal: Constraints as dictionaries

I've been asked to make a concrete proposal to fix problems brought up 
with constraints. There are three parts (ABC).


      A. Don't violate WebIDL


Constraints must be WebIDL dictionaries. We cannot afford to reinvent 
dictionaries or webidl just for Constraints, at this point. The WebIDL 
WG have thought more about JS and JS processing models than I think we 
have, and for the complexity and long-tail use-cases inherent in this 
API, we need explicit definitive language that implementers can follow, 
and WebIDL is that language.

WebIDL dictionaries ignore unknown keys. The following tweaks in our 
model let constraints be dictionaries:

  1. Conservative programmer calls if 
(!getGumKnownConstraints().hasOwnProperty("3D")) then bail
  2. getUserMedia({ mandatory: { 3D: true } }, succ, fail); // where 3D 
is ignored if unimplemented
  3. (minor) Remove limit of one key-value pair in dictionaries in 
optional array (over-specified)
  4. KeepConstrainable as a pattern, but root it in actual gUM types 
(remove abstractions, 'any' etc.)
  5. Change abstract PropertyValueRange to UnsignedLongRange, FloatRange 
etc.

Most controversial difference: The API for detecting browser-support for 
a constraint is now explicit, and gUM() itself only constrains by 
properties it knows.

This avoids blanket blocking by browser for bad as well as good cameras, 
something simple apps may not have signed on for, and lets apps 
explicitly block access on those same browsers with one line of code.

Not new: Code that plans to control the camera must already use 
getCapabilities() to learn the known things they can modify, so there is 
no added cost in those cases.

We then describe Constraints, Capabilities and Settings in the spec 
using WebIDL instead of abstract prose. I circulated 
http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0084.htmlearlier 
which shows the proposed WebIDL at the bottom. Using WebIDL 
descriptively in this manner does not preclude IANA.


      B. Don't leak


Stop returning ConstraintNotSatisfiedError, because it leaks information 
about capabilities to the website without user consent, letting a 
malicious website paint a full picture after a few visits.

Instead, always bring up the permission prompt, even when there is no 
match.The UA MUST warn the user differently of such non-matches and 
offer the Deny-equivalent choice only. The UA MUST NOT let the user 
grant access to a camera in this case (not because of a leak, but to 
give webpages an invariant for known properties).


      C. New syntax


A new syntax for Constraints only, is aimed at moving us away from the 
mandatory/optional language to a model focused on expressiveness, and 
away from Constraints being "things" to being dictionaries used in a 
pattern, just like Settings and Capabilities are now.

In this syntax, Constraints is an array of Settings (dictionaries) in 
decreasing order of preference, where a set is accepted only if all its 
specified keys are. The first accepted set is chosen.

To describe your camera preferences in fine detail, you provide all the 
combinations of settings you accept, specifying only the things you care 
about, in all the combinations you accept.

I show a width/height example here 
http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.htmlwhich 
in turn has a link to the original post.

Let me elaborate on the example in the original post (sans typo):
> Consider an alternative to:
>           { mandatory: { a, b }, optional: [ { c }, { d } ] }
> like this:
>         [ { a, b, c, d }, { a, b, c }, { a, b, d }, { a, b } ]
> Old familiars and what they look like now:
>      { mandatory: { a, b } } ==> [ { a, b } ]
> and separately:
>      { optional: [{ a }, { b }] } ==> [ { a }, { b }, {} ]

Benefits of new syntax:
+ Simpler. No keyword-dependent structure variance ([{}] vs. {}).
+ Advantage of being able to combine related things like width + height 
naturally and logically.
+ {} at the end of the array naturally makes everything optional, since 
it means "I'll accept anything".
+ More power (allows for finer, more explicit selection).
+ (AND)OR array logic is easier to read than the current optional-array 
logic (esp. width/height combos)
+ Bye bye misunderstood mandatory keyword. Hello dictionaries. <3

Cons:
- Can't handle large number of optionals, grows exponentially in 
edge-cases. (6 = ugh, 30 = no way)
   I'm banking on there always being patterns in what programmers desire 
(OR-ing sets not 1by1. Try it!)
- Pilot error: Forget ending array with {} and everything is mandatory.

Since we no longer tailor any data-types for our special needs, and rely 
solely on well-known constructs, how things work and don't work should 
be much clearer both to developers and programmers.


      Note


Again, a result of this proposal is that any invariant given a webpage 
from using mandatory constraints is now only provided for known 
constraints. Some have pointed out that this is a flimsy guarantee 
anyway, since OSes may lie.

Feel free to consider ABC individually as well as a whole.

Thanks for reading,

.: Jan-Ivar :.