Re: The mandatory constraint is a footgun

On 11/12/13 3:11 AM, cowwoc wrote:
> +1 except that there should be a requirement for ignored constraints 
> to trigger an event (for logging locally or sent back to the server). 
> This will avoid silent failures.

Old browsers are designed to ignore new features in most web APIs, 
according to Travis 
http://lists.w3.org/Archives/Public/public-media-capture/2013Oct/0129.html

Basically, we can't do it without violating webidl, so we'd need a good 
reason, which I don't think we have.

With this idea, the script can query the browser for what it doesn't 
support and send back to the server once on page-load if it wants, so no 
need for events on every API call.

.: Jan-Ivar :.

> Gili
>
> On 12/11/2013 1:04 AM, Jan-Ivar Bruaroey wrote:
>> I've implemented a strict interpretation of the spec's mandatory 
>> constraint that treats unknown keys as unsupported, I've tried it, 
>> and I think it is wrong.
>>
>> Scripts should just work, so you mustn't use 'mandatory' unless you 
>> also code up a fallback, yet we've made it the thing people try first 
>> (with its marginally preferable syntax).
>>
>> With future constraints coming, 'mandatory' is an invite to fail on a 
>> subset of browsers, a honeypot for newbie webdevs who test only their 
>> favorite browser(s).
>>
>> At the same time, 'mandatory' is a sucky api for asking what the 
>> browser supports, because you can't just ask, you have to be prepared 
>> to do.
>>
>> So it is bad for simple devs who just want to do, and bad for 
>> advanced devs who just want to ask.
>>
>> It also goes against webidl (maybe even against the web), requiring 
>> implementers to circumvent dictionaries, which, as Travis points out, 
>> disallow detection of unknown keys for this very reason 
>> (future-proofing).
>>
>> ---
>>
>> Now, all this may be justified, if there were no other way.
>>
>> But I think there is another way:
>>
>> MINIMALLY:
>>
>>  1. Browsers must have a getCapabilities() query that returns which
>>     constraints it implements.
>>  2. We clarify that mandatory constraints are webidl dictionaries,
>>     e.g. unknown keys are ignored.
>>  3. Browsers must include in webidl only the keys they actually
>>     implement.
>>
>>
>> The simple dev (with no fallback) can now just do, and things work as 
>> well as possible. This is the best outcome for this person.
>>
>> The advanced dev (with fallback) uses getCapabilites() and /then/ 
>> uses gUM with 'mandatory' to narrow sources only by the constraints 
>> the browser supports, giving them the control needed to make 
>> intelligent fallbacks.
>>
>> This works with webidl, and is webby.
>>
>> IDEALLY:
>>
>>  1. I'd love to see us go further and adopt a constraint format
>>     without the now-confusing name 'mandatory', like my "dictionaries
>>     of decreasing preference" proposal
>>     http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.html
>>
>>
>> .: Jan-Ivar :.