Re: constraints vs attributes

On 11/12/13 2:38 AM, Jim Barnett wrote:
>
> I think that the Constrainable interface is based on three largely 
> orthogonal features that distinguish it from attributes:
>
> 1.The application can query the set of legal values for the property. 
>  This is useful when the set of values is non-obvious, particularly 
> when the set of values can vary from device to device.  (Supported 
> screen resolutions would be an example.)
>
> 2.The application can request a range of values, allowing the UA to 
> choose within that range.
>
> 3.The UA may ignore the application’s request for certain values if it 
> cannot satisfy it (and this is not treated as an error)
>
> I think that Constrainable is appropriate when any of these three 
> conditions holds.  Attributes are suitable when:
>
> 1.There is no need to query the set of legal values because all 
> devices support the same ones.
>
> 2.The app needs only to specify a specific value (or ranges don’t make 
> sense).
>
> 3.The UA must accept the value the app specifies (as long as it 
> matches the attribute’s type).
>

I think this is a false choice. At least it should be: constraints vs. 
dictionaries vs. attributes.

In fact, I would argue #1, #2 and #3 (the first ones) are all features 
of using webidl dictionaries, not constraints.

I find the distinguishing feature of constraints to be the functionality 
it adds beyond what's achieved through mere convention of 
dictionary-passing:

 1. The application can select from a collection of undisclosed yet
    discrete property-holding choices, based on need (mandatory) and
    ordered preference (optional).


In other words, I find constraints useful for describing recipes for 
picking objects.

Specifically, I would not use constraints in an API unless we're 
operating on a collection of choices (you call them 'devices'), because 
of the complexity, confusion and implementation cost this adds.

An example of cost:

The PeerConnection settings, OfferToReceiveAudio, OfferToReceiveVideo 
etc. fail my constraint-test, not because they are booleans, but because 
we're not picking from a collection of discrete property-holding objects 
inside a PeerConnection (an architecture I hope one would not choose 
without external reasons, because it complicates the API for internal 
reasons).

The implementation cost is that the spec requires me to "preserve the 
order of the optional keys", which is a hardship as I cannot flatten 
this structure of simple settings inside the implementation (when even 
the mandatory/optional state falls away after settings are set). 
Instead, I must carry this state around for no reason - there's no 
algorithm and no collection of objects to re-apply these "rules" to - 
and deal with additional rules governing how to pass around and 
manipulate these things which are of no benefit.

The confusion and complexity cost is that this is harder than it needs 
to be.

> So things with Boolean values should be attributes (this is the 
> opposite of what I said on the call). So should things whose values 
> can be any string or any int.
>

.: Jan-Ivar :.