Re: Constraints 2014

Assuming that Capabilities and Settings are not controversial, the main 
requirements on Constraints that I recall have been the following (if 
I've missed any, I'm sure someone will correct me):

1. Clear distinction between mandatory and optional constraints, namely 
all mandatory constraints must be satisfied or the error callback is 
called.  Optional constraints may or may not be satisfied.

2.  Unknown/unsupported mandatory constraints must fail.  (Success 
callback means that all constraints are known to be satisfied.)

3.  It must be possible to implement back-off using optional constraints.

4.  It should be possible to couple constraints, to say, for example: I 
prefer an aspectRatio of 15/6 and width of 500.  If I can't have both of 
those then give me aspectRatio of 4/3 and width of 400, etc.  (This is 
an example of both back off and of  coupling optional constraints.)  
Mandatory constraints are always coupled because they all must be 
satisfied or the api call fails.  (I'm putting this as a 'should', not a 
'must' because there wasn't as much discussion/demand for it, but 
several people wanted it and no one didn't want it.)

5.  The application must be notified if changing circumstances result  
in previously satisfied mandatory constraints becoming unsatisfied.

The lengthiest dispute/discussion was over whether the application 
should be notified which mandatory constraints failed.  Some people felt 
this made fingerprinting too easy, others felt that information was 
important for intelligent applications.   The latter group has prevailed.


On 3/23/14 9:06 AM, Jim Barnett wrote:
> +1. The current constraints proposal satisfies a number of requirements that we have elaborated in repeated and extensive discussions.

Would it be useful to re-summarize those exact requirements at this
juncture?

.: Jan-Ivar :.


-- 
Jim Barnett
Genesys

Received on Sunday, 23 March 2014 21:52:41 UTC