Re: Proposal: Constraints as dictionaries

On the whole, I kinda like A and C, but I have a number of concerns.
B is something that I need to think about more.  There's a tradeoff
there.

I think that this is just an oversight, but you haven't allowed for
the distinction between different source types very well in A.  And,
given that different source types are going to be very different in
terms of what constraints are supported, you either need to fix
getSupportedConstraints() so that it returns different values for
different types of sources, or maybe you can avoid it altogether and
just have someone construct a track and poke around in the result from
capabilities().

In terms of the different range values, I think that a single
NumericPropertyRange is going to be sufficient.  These generalize
fairly well, even if the full, possible, specified range isn't
exercised.  For instance, 0.3 to 10.1 is for all intents equivalent to
1 to 10 in ordinal values.  If the application wants to specify 0.3 to
0.4 on a property that only supports ordinal values, that's
overconstrained.  That's how JavaScript works anyway.  I don't see any
reason to provide ranges for things other than numbers, but if we do,
that can be arranged.

I like C a lot, especially since it effectively changes the behaviour
in response to a naive choice [{ stuff I want }] to the intuitive
behaviour, i.e., mandatory.



On 20 November 2013 13:30, Jan-Ivar Bruaroey <jib@mozilla.com> 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. Keep Constrainable 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.html
> earlier 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.html
> which 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 :.
>

Received on Thursday, 21 November 2013 01:28:10 UTC