Re: Proposal: Constraints as dictionaries

On 20/11/2013 3:13 PM, Jan-Ivar Bruaroey wrote:
> 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 
> available).
>
> 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 guess I agree with Martin here. I don't mind A and C so much as B. 
There is a trade-off between troubleshooting and fingerprinting and I 
have yet to be convinced that the only solution is to remove important 
diagnostics information. WebRTC applications are already very difficult 
to troubleshoot, and this is going to make it even harder.

We need to find a solution that does not require us to choose one or the 
other. We should be able to get both.

Gili