Re: Bug 23935 - Proposal: New syntax for constraints

On 12/13/13 7:52 AM, Harald Alvestrand wrote:
> On 12/12/2013 06:45 PM, Jan-Ivar Bruaroey wrote:
>> Constraints aren't applied cumulatively AFAIK, so in the current 
>> algorithm I believe you are wrong here.
>
> Sorry, that's an invalid interpretation of the specification.
>
> From section 10 (constrainable)
>
> The ordering of optional constraints is significant. In the example in 
> the previous paragraph, suppose that aspect ratio constraint is 
> mandatory and that the height and width constraints are optional. If 
> the height constraint is specified first, then it will be satisfied 
> and the width constraint will be ignored. Thus the height will be set 
> to 600 and the the width will be set to 400. On the other hand, if 
> width is specified before height, the width constraint will be 
> satisfied and the height constraint will be ignored, resulting in 
> width of 500 and height of 750.
>
>
>> It seems to me that a camera that can handle both 4096x2160 and 
>> 2880x1800 settings will gladly satisfy both constraints, unaware of 
>> context. It seems to me that to work the way you wanted, cameras 
>> would need to know that they've already agreed to one setting and 
>> refuse another setting, which it doesn't have enough context to do, 
>> so the algorithm would need to be altered to track cameras and what 
>> they've previously agreed to.
>
> Constraints aren't interpreted by the camera, they're interpreted by 
> the UA, which is perfectly aware of all the constraints. The UA then 
> makes a decision on what it asks the camera to do.

You're totally right. Sorry, my bad.

OK lets try to work with that.

How about this for a new syntax:

 1. Boost the optional array as you show (entries take multiple
    key-value-pairs)
 2. Remove mandatory.


Done. Much simpler. User always gets prompted, user accepts, then app 
gets full access to query all they want and say "sorry, your camera 
ain't good enough". The only difference is the user got his hopes up by 
getting a prompt first, but he also got a prompt before the website 
learned of his camera details, so hate it or like it.

(Simpler) example:

[ { width: 4096, height: 2160 },
   { width: 3840, height: 2160 },
   { width: 2880, height: 1800 },
   { width: { min: 1024 }, height: { min: 768 } }
]

And if we truly truly can't live without promptless denial, we could add 
a 'required' sub-key, like this:

[ { width: 4096, height: 2160 },
   { width: 3840, height: 2160 },
   { width: 2880, height: 1800 },
   { width: { min: 1024, required: true }, height: { min: 768, required: 
true } }
]

This also makes mandatory slightly harder to specify by accident, which 
we said we wanted.

Detail: we'd need to accept a 'value' key to use 'required' with plain 
values:

[ { width: 2880 },
   { height: { value: 1800, required: true },

Here, width is optional and height is mandatory. In this example, width 
still goes first, which you couldn't do before.

Thoughts?

.: Jan-Ivar :.