Re: gUM constraints webidl implementer feedback

On 10/16/13 6:42 AM, Harald Alvestrand wrote:
> On 10/15/2013 08:28 PM, Jan-Ivar Bruaroey wrote:
>>
>>  1. Why not THROW on unsupported mandatory constraints? Our generated
>>     webidl bindings already throw for us on various syntax and type
>>     errors, and this way, should webidl ever grow, say, an extended
>>     attribute feature that make a dictionary throw on unknown
>>     entries, then we could use it out of the box (right now they're
>>     ignored, which is a problem - see below).
>>
>
> I believe a dictionary is designed to allow unknown members by default 
> (I could be wrong).
> In our implementation, the place that checks whether constraints are 
> supported or not is a couple of process switches away from the place 
> where the IDL checks get done, so it's convenient for us to use the 
> error callback.

You use callbacks for (web?)IDL checks?

>>  1. Why not allow multiple keys in each object in the optional array?
>>       * When implementing this, it became obvious pretty soon that
>>         reusing the sameapply() function for optional constraint
>>         entries as for the mandatory constraints was
>>         desirable.There's really no cost to implementation of doing
>>         this. In fact, I found there to be a high cost of
>>         implementation to consider anything else. That's because it
>>         would need to be spec'ed if you ask webidl guys. These guys
>>         are extremely pedantic about processing models in JS (for
>>         good reason: two ways of doing things in JS are never the
>>         same, which means side-effects and security issues w.r.t.
>>         malignant objects must be nailed down). So reusing the
>>         established dictionary processing model here seems like a win.
>>
>>       * Here's how I implement it today in webidl:
>>           o // MediaTrackConstraint = single-property-subset of
>>             MediaTrackConstraintSet
>>             // Implemented as full set. Test Object.keys(pair).length
>>             == 1
>>             typedef MediaTrackConstraintSet MediaTrackConstraint;
>>
>
> The only reason I remember for not having multiple keys in each object 
> in the optional array is that if you have more than one constraint in 
> an optional array element, it's more confusing if one of them can be 
> satisfied and the other one can't. Does the one that can be satisfied 
> get ignored because of the failing one, or is it one applied and one 
> ignored?

In my mind, they'd both be ignored since they're specified together, but 
I appreciate how it might lead to pilot-error.

---

I hesitate to ask this late, but did anyone ever consider an alternative to:

     { mandatory: { a, b }, optional: [ { c }, { d } ] }

like this:

   [ { a, b, c, d }, { a, b, c }, { a, b } ]

i.e. (a AND b AND c AND d) OR (a AND b AND c) OR (a AND b)

The web developer specifies "I want this set, or if I can't have exactly 
that, then I want this other set, or if I can't have exactly that etc." 
- This seems a lot clearer to me than our present optional-array-logic.

.: Jan-Ivar :.