No-change proposals for WebIDL for constraints

I think we're landing on the basic structure of constraints as retaining 
the properties it has:

- Mandatory is a set of key/value pairs, where all of them need to be 
satisfied in order for the allocation to succeed. If the browser does 
not understand a key, it does not succeed. (I know Jan-Ivar doesn't agree.)

- Optional is a sequence of sets of key/value pairs. (I'm suggesting 
that we relax the rule of only one key/value pair for each element in 
the sequence). The browser will try to satisfy as many constraint sets 
as it can, but will ignore constraint sets that cannot be satisified, 
these will not cause the call to fail.

The Mandatory set of key/value pairs doesn't have the same semantics as 
Dictionary. Therefore it is not a Dictionary.

Existing deployed code is expecting this code to be correctly parsed:

getUserMedia(.... { mandatory: { a=b}, optional: [ {c=d} ]})

It would be nice to keep that representation parsing.

The following suggestions are all valid IDL for the Constraints 
construct in section 10.1.4.4 of the current getusermedia spec (which is 
currently incomplete):

dictionary Constraints {
    ConstraintSet? mandatory;
    sequence<ConstraintSet> _optional;
};

Alternative 1:

ConstraintSet = object. This will Just Work, with the usual caveats 
about generated code needing to deal with Object.

Alternative 2:

[MapClass(DOMString, Constraint)] interface ConstraintSet {
    ... boilerplate may go here ...
}

Alternative 3:

[Constructor that takes an Object prototype]
interface ConstraintSet {
    get Constraint(DOMString)
    set(DOMString, Constraint)
}


These may or may not parse the constant notation mentioned earlier. I 
can't read the IDL spec to affirm or deny that.

Constraint can be a Dictionary. No property of Dictionary was harmed in 
this writing.
But I think Jan-Ivar's proposal for "valid IDL" may work better at this 
level.

http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0084.html