Re: Conclusions from the constraints spec review

On 02/11/2014 03:41 AM, Jan-Ivar Bruaroey wrote:
> 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.


I don't find the ask-inspect-reject pattern either simpler or more natural.

In fact, the first time I discovered the WebIDL enum pattern where, if
you set an object to an illegal value and have to inspect it in order to
figure out whether your modification "took" or not, I was shocked.

We don't have the same view of what's natural.
But I think I'll stop repeating myself. There are other participants in
the WG than you, me, EKR and roc; most of them have said nothing.


>
>> 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?

Oh yes!
Cameras in particular are, at times, *awful*.
In general, anything to do with hardware can cause arbitrary delays.

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


-- 
Surveillance is pervasive. Go Dark.