Re: About the Mandatory constraints

So for the record, I'm still against the mandatory constraints API. The 
main driver for it seems to be preventing browser fingerprinting which, 
I have repeatedly argued, is a lost battle (it is impossible to prevent 
fingerprinting, and there is already enough data out there to 
fingerprint browsers whether we expose extra information or not). I'd be 
interested in hearing the chairs' position on this matter.

 From a usability and flexibility point of it, it makes much more sense 
to allow the developer to query the camera capabilities, pick a specific 
video mode and only prompt the user for permission before opening the 
camera. The developer is in a much better position than the browser to 
fail gracefully when application requirements are not met, and to 
present users with an easy to understand explanation of what went wrong 
and how to resolve the problem.

Let's answer the question about browser fingerprinting first, because it 
affects multiple API function points.

Gili

On 06/02/2014 4:38 AM, Stefan Håkansson LK wrote:
> On 2014-02-06 05:28, cowwoc wrote:
>> Hi Stefan,
>>
>> Correct me if I'm wrong, but doesn't the Capabilities API enable 
>> developers to query a camera's capabilities, before invoking 
>> getUserMedia(), all without triggering a prompt?
>
> No, I don't think so. getCapbilites is available on (Constrainable of) 
> MediaStreamTrack; that track is in turn connected to the camera (as an 
> example).
>
> But to get that MediaStreamTrack you need to call getUserMedia - so 
> without it there is no "getCapabilities".
>
>>
>> If so, why do we need mandatory/optional constraints at all? The 
>> developer can filter the reads of getCapabilities() and judge for 
>> themselves if their desired constraints are met or not. The 
>> constraints API is always going to be less expressive than a 
>> developer querying and filtering through the Capabilities themselves.
>>
>> I am expecting something along these lines:
>>
>>  1. var capabilities = Camera.getCapabilities();
>>  2. var preference = pickBest(capabilities); //application-specific
>>     definition of "best"
>>  3. If "preference" is undefined, the mandatory constraints were not
>>     met. Display a user-friendly error message and quit.
>>  4. Otherwise, invoke: getUserMedia(preference); //Provide a specific
>>     mode to open the camera in
>>  5. If the operation fails (the user disconnected the camera between
>>     steps 1 and 3) go back to step 1 and try again.
>>
>> Gili
>>
>> On 05/02/2014 1:34 PM, Stefan Håkansson LK wrote:
>>> There has been some discussion about mandatory constraints again lately
>>> in the context of constraints for the MediaStream Recorder.
>>>
>>> I think the use of constraints for the Recorder is something we have not
>>> really discussed yet, but I think (though I may be wrong) some mails
>>> tended to question the need for mandatory constraints also for gUM.
>>>
>>> Just to be clear: I think we have debated the mandatory constraints for
>>> gUM several times, and we always come back to the same conclusion:
>>> people want them. One use is when the app developer wants to avoid
>>> disturbing the user, or even indicate e.g. that video communication is
>>> possible, if the equipment does not fulfill the requirements the app
>>> developer has.
>>>
>>> Some people think it would be more natural to just get access to the
>>> camera (and in the process launch a prompt), then check what it can
>>> fulfill the needs, and if not tell the user that "sorry, your camera is
>>> not good enough". But those developers can skip using mandatory constraints.
>>>
>>> Let's not debate if we need mandatory constraints or not for gUM again.
>>> I think it would be much more fruitful if we could have the details in
>>> Constrainable reviewed for use with gUM and MediaStreamTracks. I would
>>> be really happy we could nail a design that fulfills the needs we have
>>> there.
>>>
>>> Stefan
>>>
>>
>