Re: gUM constraints webidl implementer feedback

On 10/19/2013 01:38 AM, Jan-Ivar Bruaroey wrote:
> So we can't add more mandatory constraints over time?
>
> Define "not to support any random property". Fail or silently succeed?

The behaviour I want is:

getUserMedia(.... mandatory(knownKey='foo', unknownKey='bar') ...)

should call the error callback ("constraints can't be satisfied"), with 
"unknownKey='bar'" as the constraint that couldn't be satisfied.

getUserMedia(.... optional((knownKey='foo'), (unknownKey='bar')) ...)

should silently succeed.

If that means dictionaries aren't the right object, we'll have to use 
something else.


>
> .: Jan-Ivar :.
>
> On 10/17/13 4:22 PM, Travis Leithead wrote:
>>
>> WebIDL dictionary processing only knows how to deal with known 
>> dictionary members (see 
>> http://dev.w3.org/2006/webapi/WebIDL/#es-dictionary). Dictionaries 
>> are not generic property maps or sets.
>>
>> In getUserMedia, the intention is to have a set of well-defined 
>> mandatory constraints (as defined by dictionaries in the spec--or 
>> inherited/partial dictionaries defined formerly elsewhere)---not to 
>> support any random property key that is placed on the dictionary 
>> object by user code.
>>
>> *From:*Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
>> *Sent:* Wednesday, October 16, 2013 12:40 PM
>> *To:* Harald Alvestrand; public-media-capture@w3.org
>> *Subject:* Re: gUM constraints webidl implementer feedback
>>
>> On 10/16/13 6:42 AM, Harald Alvestrand wrote:
>>
>>     On 10/15/2013 08:28 PM, Jan-Ivar Bruaroey wrote:
>>
>>          1. Mandatory constraints aren't implementable as webidl
>>             dictionaries.
>>
>>               * We're supposed to detect unknown mandatory
>>                 constraints and fail on them, but webidl dictionaries
>>                 /silently ignore/ unknown keys!
>>
>>
>>     I thought this was a feature... don't you get to see the ignored
>>     keys in the engine?
>>
>>
>> No, our webidl-compiler-generated bindings create a new dictionary 
>> from default values and then interrogates known members it finds in 
>> the provided content JS object through inspection. This is for 
>> security reasons, as content JS objects may be toxic. - Unknown 
>> members have unknown types, so including them safely becomes tricky.
>>
>>
>>         1.
>>
>>               * To work around this problem, I had to alter the API
>>                 to take the mandatory member as a plain object (which
>>                 makes our webidl security guys' neck-hair stand up,
>>                 but it's ok), like this:
>>
>>                   o dictionary MediaTrackConstraints {
>>                         object mandatory; // so we can see unknown +
>>                     unsupported constraints
>>                         sequence<MediaTrackConstraint> _optional;
>>                     };
>>
>>               * I then convert it internally to this structure after
>>                 scanning for unknown keys, which should be safe:
>>
>>                   o dictionary MediaTrackConstraintsInternal {
>>                         MediaTrackConstraintSet mandatory; // holds
>>                     only supported constraints
>>                         sequence<MediaTrackConstraint> _optional;
>>                     };
>>
>>
>>         In lieu of alternative solutions to number 6, I'd like to see
>>         the spec be explicit about what's needed to implement this as
>>         it stands.
>>
>>
>>     Seems to me we have a differing understanding of how the engine
>>     should deal with dictionaries.
>>
>>
>> I agree. Maybe the webidl group can help clarify?
>>
>> .: Jan-Ivar :.
>>
>
>
> -- 
> .: Jan-Ivar :.