Re: The UNKNOWN mandatory constraint behavior is a footgun

On 11/15/13 8:31 AM, cowwoc wrote:
> On 15/11/2013 12:48 AM, Adam Bergkvist wrote:
>> On 2013-11-15 01:12, Silvia Pfeiffer wrote:
>>> How does "making it harder to use an API" meet any requirements at
>>> all? I really don't understand that request.
>>> You're assuming Web developers are dumb and if you make it hard enough
>>> to use something, they will stop using it.
>>> Instead what will happen is that they search StackOverflow for
>>> solutions on how to achieve a certain goal and if that involves
>>> mandatory constraints, they will get a recipe there on how to achieve
>>> it, copy it and be done.
>>> How hard it is to use an API has no (I repeat: *absolutely no*)
>>> influence on how often an API is being used.
>>> Let's not kid ourselves.
>>>
>>> So, in view of this: go ahead and try to make it harder. Us Web Devs
>>> really like a challenge - it's what we've become used to when dealing
>>> with Web standards and browsers. :-)

I agree with Silvia that making mandatory constraints harder to use is 
wrong-headed (which is why I renamed the subject). As the raiser of the 
concern that probably sparked this, it does not address my concern, 
which was specifically about constraints not known to the UA. - I'm 
trying to fix mandatory constraints so that they're smarter and safer, 
not leave them unsafe with a warning light.

>>>
>> I interpret our resolution that mandatory constraints should  be "harder
>> to use" symbolic and not the real desire. We've said that mandatory
>> constraints should be the last resort if the app really can't function
>> without a specific feature; a bit of an edge case. Then should we
>> optimize for that case as we optimize for regular (optional) 
>> constraints?
>>
>> My preference would be that we just have constraints, and the thing that
>> makes a constraint mandatory is the result of the action taken when that
>> constraint fails.
>
> We should just abolish mandatory constraints. We should just let the 
> developer pass in a list of priority-ordered constraints and the API 
> will try to meet those to the best of its ability. The developer can 
> then scan the list of accepted constraints and if one of its 
> "mandatory" ones is missing, it can take the appropriate action.
>
> The concept of "mandatory" only really makes sense to the developer. 
> The browser isn't really handling mandatory constraints anyway. It is 
> throwing an exception for the developer to handle.

The prime feature of mandatory is not that it fails (callback btw. not 
exception). If it were it could be a boolean. The prime feature is 
expressiveness. (In fact I argue in

If we just take out mandatory now, then I worry the optional structure 
alone isn't expressive enough to handle some of the width/height min/max 
cases I've seen. Don't we risk the browser (putting the wrong camera at 
the top of the choice-list and) returning the wrong camera? I think it 
is essential that getUserMedia() return the best camera the first time.

Gili, if you are referring to my "dictionaries of decreasing preference" 
proposal 
http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.html 
, then I agree with you, as that structure supports (AND)OR implicitly.

If you're arguing we should not throw ConstraintNotSatisfiedError then 
that's 
http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0078.html 
and I agree. The app should inspect what's returned instead. No need to 
optimize for failure.

.: Jan-Ivar :.