Re: Conclusions from the constraints spec review

On 2/10/14 2:46 PM, Harald Alvestrand wrote:
> On 02/08/2014 05:56 PM, Jan-Ivar Bruaroey wrote:
>> On 2/8/2014 11:00 AM, Eric Rescorla wrote:
>>> On Fri, Feb 7, 2014 at 11:14 PM, Jan-Ivar Bruaroey <jib@mozilla.com 
>>> <mailto:jib@mozilla.com>> wrote:
>>>
>>>
>>>
>>>     To repeat: Constrainable is only warranted when you're sharing
>>>     resources behind a permission prompt. Sound general?
>>>
>>>
>>> For the record, I don't believe agree with these statements.
>>>
>>> There are plenty of reasons why one would wish to have mandatory API
>>> points, not just for things behind a permissions promot.
>>
>> Avoiding the permission prompt is what necessitates building the 
>> intent missile. Without that problem, it is much simpler and natural 
>> to ask, look at what you get and reject it, like roc says.
>
> That's your theory. I don't agree with that theory.

OK let me rephrase to avoid the "it's all just theory":

Avoiding the permission prompt necessitated building the intent missile. 
Without that problem, another approach become feasible, which is to look 
at what you get and reject it, like roc says.

Without saying which approach is better, more concise or more usable, 
the ask-reject approach is a simpler construct because constraints are 
*relatively* complex in nature.

We should strive to use the simplest construct for a given problem.

> Speaking for myself only, the aspects of using constraints rather than 
> a set/inspect/set again cycle that I think are important are:
>
> - Clear statement of the user's hierarchy of requirements: What it 
> must have, what it would prefer to have, and what it would want to 
> have as a backup option.
>
> - Ability to state that requirement hierarchy in a single cycle. Yes, 
> this helps with the permissions prompt issue, but it also makes sense 
> for things like slowly initializing devices.

Do we have slowly initializing devices?

> - Ability to state a range within which any value is satisfactory 
> rather than guessing at which value to set in order to achieve a given 
> effect; this makes it easier to allow for future evolution where the 
> set of reasonable values changes than the "set something that makes 
> sense today, and hope the UA tweaks it the right way" approach.

Ranges are just as doable with dictionaries and are not exclusive to 
constraints. In fact, the ask-check pattern fits well for this, because 
if you ask for a range, then if you care what you got you must query to 
learn the actual value you received.

.: Jan-Ivar :.