RE: constraints vs attributes

Jan-Ivar,
For my edification, can you explain how the use of a dictionary lets you do the following:

1.       Ask the device what range of framerates it supports?

2.       Request that the device set a framerate between n and m frames per second

3.       Request the above, but allow the UA the choice of choosing another framerate if it can't set it to something between n and m.


-          Jim

P.S.  Perhaps there's some terminological confusion here.  The question asked was when to define something as a property inside the Constrainable interface as opposed to an attribute.  The Constraint structure is only one part of that interface.

From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
Sent: Wednesday, November 13, 2013 3:51 PM
To: Jim Barnett; public-webrtc@w3.org
Subject: 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 :.