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>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]
> *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 :.
>