W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2013

Re: Proposal: Constraints as dictionaries

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Wed, 20 Nov 2013 18:13:07 -0500
Message-ID: <528D4203.1030808@mozilla.com>
To: Gili <cowwoc@bbs.darktech.org>, public-media-capture@w3.org
On 11/20/13 4:57 PM, Gili wrote:
> Hi Jan,
> I'm +1 for collapsing "mandatory" and "optional" into a simple 
> dictionary, but -1 for ignoring unsupported capabilities (which I see 
> as "silent failures").

Therein lies the conundrum. You cannot have both. You cannot have 
"simple dictionaries" and then reject how they work. The current spec 
mis-states that constraints are passed as dictionaries in several 
places, which is misleading and wrong, and cannot be implemented. If 
this proposal is rejected, all such language must be removed and 
replaced with JS objects.

Furthermore, I have demonstrated that your "silent failures" contain a 
sub-set of valid cameras that work fine when you don't need to control 
them actively (which you can't today anyway). That seems like a poor 
definition of failure (conversely, for cameras that do offer active 
control, there's no problem, since getCapabilities() tells you what's 

Your app can query the browser directly for what it supports and take 
the extreme action of blocking all users of that browser regardless of 
what camera they have, if that's right for you.

I like that this proposal puts it on you to take this extreme action, 
rather than have it happen implicitly.
I like that it doesn't assume you want this extreme behavior.
I like that people can express narrow constraint combinations (which is 
what mandatory is for btw) without worrying whether browsers have caught up.
I like that we can define constraints as dictionaries, and the 
simplicity this brings to the spec.
I like that you only need one line of code to have what you want.

To me, those five points far outweigh the (not even loss of but) 
convenience of the carpet-bomb-invariant, which if OS'es are lying, you 
shouldn't rely on too heavily anyway.

> I would counter that unsupported capabilities should trigger a 
> failure, and if the capability is not vital, the application should 
> repeat the operation with the capability removed. Meaning:
> var capabilities = {a, b, c};
> getUserMedia(capabilities, onSuccess, onFailure);
> function onFailure(capability, reason)
> {
>   if (reason === Errors.UNSUPPORTED && capability === "a")
>   {
>     removeFromArray(capabilities, "a");
>     getUserMedia(capabilities, onSuccess, onFailure);
>   }
>   else
>     notifyUserOfFailure();
> }

This leaks, which was point B.

Please read the whole proposal and try to appreciate that the word 
mandatory is gone, and what that means.

.: Jan-Ivar :.
Received on Wednesday, 20 November 2013 23:13:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC