RE: constraints vs attributes

This is a question of what structure  to pass to certain functions and is thus separate from the question of that I was addressing (which is what should  be defined as part of a Constrainable interface, as opposed to being an attribute on the underlying object.)

In the case of arguments to a function, one advantage of using a Constraints structure would  be that the intended semantics are clear, in particular the difference between mandatory and optional constraints  (plus the possibility of getting back-off by using multiple optional constraints on the same property.)  If we pass a dictionary, we have to explain what the semantics of the dictionary entries are for each function.  However, in cases where the semantics are easy to explain, that’s not a big problem.    For example, if the semantics of the dictionary are:  set the corresponding attributes to these values (i.e., mandatorily)  then a dictionary works fine.

Looking through the constraints defined in section 16.1 of the webRTC spec, I do see a mention of a mandatory vs optional distinction, which would indicate that at least some of the uses do seem to have the semantics of Constraints (as defined in the Constrainable interface).  Other uses may not.


-          Jim

From: Justin Uberti [mailto:juberti@google.com]
Sent: Wednesday, November 13, 2013 4:10 PM
To: Jim Barnett
Cc: Jan-Ivar Bruaroey; public-webrtc@w3.org
Subject: Re: constraints vs attributes

+1 to use of dictionaries in createOffer and createAnswer.
I think the constraints in addStream can be removed and replaced with the doohickey, aka MediaStreamTrackSender.
Which just leaves the global PeerConnection constraints, which can probably also be replaced with a dictionary, or moved into RTCConfiguration.

On Wed, Nov 13, 2013 at 1:00 PM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
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<mailto:jib@mozilla.com>]
Sent: Wednesday, November 13, 2013 3:51 PM
To: Jim Barnett; public-webrtc@w3.org<mailto: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 :.