Re: No-change proposals for WebIDL for constraints

On 12/16/13 12:43 PM, Harald Alvestrand wrote:
> 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.)

Right, but I'll pocket my disagreement for a moment in order to comment 
on the rest.

> - 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.

+1.

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

I would argue that the sets of key/value pairs in the Optional array 
don't have the semantics of a Dictionary either, unless we're fine with 
{ optional: [{facingMode:"up"}] } causing an exception.

> 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.

Do you mean ':' not '='?

> 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.

This is the only alternative here that is backwards compatible.

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

MapClass doesn't have any constructor semantics of its own, so this is 
still an interface that needs a constructor.

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

Any new interface is going to require explicit creation by name, and 
wont be source-compatible with existing deployed code. So if that's your 
goal here then both alternatives 2 and 3 fail.

That said, I find backwards compatibility to be a lousy design 
principle. Lets find the ideal API without worrying about backwards 
compatibility first. There may be tons of ways to solve backwards 
compatibility for anything we come up with.

A MapClass has setters and getters, so we might as well combine 
alternatives 2 and 3 for discussion:

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

But still, having 'Constraint' be a dictionary in a MapClass is weird, 
since the key is now both in the DOMString and in the dictionary.

Disclaimer: I know I've pushed for 
http://heycam.github.io/webidl/#MapClass in the webrtc spec, but beware 
that it is still unfinished. In fact, I'm backing off a bit on using it 
in RTCStatsReport, see https://bugzilla.mozilla.org/show_bug.cgi?id=950855

> 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

See my comment on facingMode above. I think the current constraint 
format makes naive assumptions about dictionary===object.

.: Jan-Ivar :.