W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2014

Re: Conclusions from the constraints spec review

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 10 Feb 2014 23:46:26 +0100
Message-ID: <52F956C2.8050001@alvestrand.no>
To: Jan-Ivar Bruaroey <jib@mozilla.com>, Eric Rescorla <ekr@rtfm.com>
CC: Robert O'Callahan <robert@ocallahan.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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.

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.

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

- Ability to state which changes in requirements necessicate signalling
to the app (onconstraintfailure) and which can be done "behind the
scenes" without explicit notification

- Uniform ability to find valid values for attributes (getCapabilities)
and their current values (getSettings) (that's the main reason I'm
willing to add these

> Mandatory constraints, with their WebIDL headaches and confusing
> semantics favoring a non-webby fail-first approach [0], would not have
> survived discussion without the permission prompt problem.

I know you are unconvinced. However, I am also unconvinced by the
arguments you have fielded against them. So we're kind of even on that

I'm happy that we agree that mandatory / optional makes sense in the
permissions prompt case.

Received on Monday, 10 February 2014 22:47:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:24 UTC