Re: [Bug 23933] Proposal: Change constraints to use WebIDL dictionaries

On 05/12/2013 11:30 PM, Jan-Ivar Bruaroey wrote:
> On 11/28/13 12:37 PM, cowwoc wrote:
>> On 28/11/2013 2:51 AM, bugzilla@jessica.w3.org wrote:
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23933
>>>
>>> Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> changed:
>>>
>>>             What    |Removed                     |Added
>>> ---------------------------------------------------------------------------- 
>>>
>>>              Summary|Change constraints to use   |Proposal: Change
>>>                     |WebIDL dictionaries         |constraints to use 
>>> WebIDL
>>>                     |                            |dictionaries
>>>
>>> --- Comment #2 from Stefan Hakansson LK 
>>> <stefan.lk.hakansson@ericsson.com> ---
>>> (In reply to Gili from comment #1)
>>>> Just to be clear: the implication of this proposal is that users 
>>>> will need
>>>> to ask for a set of constraints, but then they will have to check 
>>>> that the
>>>> returned device meets those constraints (because some of them may 
>>>> have been
>>>> omitted as "unknown").
>>> That is not true really. Since the proposal also includes a method 
>>> that allows
>>> the app to probe for what constraints that the UA understands, it 
>>> can first
>>> check, and if one or more constraints the app wants to use as 
>>> mandatory are not
>>> known by the UA the app can at that stage decide to not go ahead and 
>>> call gUM.
>>>
>>
>> In light of that fact, I don't understand the benefit of ignoring 
>> unknown constraints. If the user has the ability to detect unknown 
>> constraints and *still* insists on passing them into getUserMedia() 
>> shouldn't we fire the error listener?
>
> Please understand that Webidl dictionaries ignore unknown keys.
>
> From http://heycam.github.io/webidl/#idl-dictionaries :
>> "A dictionary value of type D can have key–value pairs corresponding 
>> to the dictionary members defined on D and on any of D’s inherited 
>> dictionaries."
>
> This is on purpose for future-proofing, and all other web APIs (that 
> use dictionaries at least) are on-board with this. AFAIK it is only 
> our freaky mandatory constraints that fly in the face of this.

I don't think you understood my point. There are two ways to support 
"future proofing": One is to ignore unknown keys, and the other is to 
support a mechanism for looking up supported keys. If you've got one, 
you don't need the other. Anyone who wants to "future proof" the 
dictionary just needs to use the function that returns all known 
constraints as a filter (meaning, remove any key in the dictionary that 
is not returned by the function). That's it, that's all. As such, There 
is no reason to ignore unknown keys.

> Our spec is not implementable as it stands, because it speaks about 
> mandatory constraints being dictionaries.
> Our spec sorely needs review by the webidl experts group.

I get your point about Dictionary as defined by WebIDL but I think 
you're splitting hairs. If the only reason you want to ignore unknown 
constraints is for the sake of meeting the WebIDL specification then 
rename the type from Dictionary to something else that allows you to 
throw an error on unknown constraints.

> This bug is about fixing our API to use plain webidl dictionaries 
> instead of reinventing webidl. It doesn't take much and we can live 
> with it.
>
> With this fix, the error listener will only fire when the browser 
> knows what it is doing and it knows that all cameras are wrong.
>
> If I truly want nothing to work unless the browser supports constraint 
> x (like gUM() works today) then I just bail early. No need to involve 
> gUM() at all.

So what you're saying is that instead of the function validating its 
input, it should lead such validation to the user and assume that they 
will never pass in anything invalid. I understand that's not what you 
mean, but practically speaking it results in the same behavior. 
Definitely a no no in my books.

> If on the other hand, I choose not to bail and I proceed, the new 
> gUM() behavior errs on the side of working, giving me positives, 
> negatives and false positives, instead of just all negatives when 
> constraint x is involved. This has merit, because it avoids sweeping 
> false negatives until browsers catch up. See footgun-relief example: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=927358

Firefox only needed to implement this behavior because there was no 
mechanism for developers to check what keys were supported by the 
browser. Now that we are adding this mechanism, ignoring unknown keys is 
no longer helpful. This function will allow you to ignore false 
negatives until browsers catch up, and throughout the entire process you 
can rest assure that the browser will throw an exception on user error.

Consider the alternative:

{ audio: true, video: { mandatory: { maxW1dth: 320, maxHeight: 240 }}}

Do you know how much of my life has been wasted dealing with these kinds of stupid typos? This is why I am so strongly opposed to ignoring errors silently.

Gili

Received on Friday, 6 December 2013 06:05:58 UTC