Re: Proposal: Constraints as dictionaries

Hi Jan,

I'm +1 for collapsing "mandatory" and "optional" into a simple 
dictionary, but -1 for ignoring unsupported capabilities (which I see as 
"silent failures"). I would counter that unsupported capabilities should 
trigger a failure, and if the capability is not vital, the application 
should repeat the operation with the capability removed. Meaning:

var capabilities = {a, b, c};
getUserMedia(capabilities, onSuccess, onFailure);
function onFailure(capability, reason)
{
   if (reason === Errors.UNSUPPORTED && capability === "a")
   {
     removeFromArray(capabilities, "a");
     getUserMedia(capabilities, onSuccess, onFailure);
   }
   else
     notifyUserOfFailure();
}

This allows you to provide backwards compatibility without silent failures.

Gili

On 20/11/2013 1:30 PM, Jan-Ivar Bruaroey wrote:
> 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 :.
>