- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 14 Nov 2013 05:36:17 -0500
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Someone mentioned that constraints are about needs and wants. I love
that, because it's as descriptive of the application as it is
prescriptive of the browser and its user (unlike those other unilateral
terms).
It's getUserMedia(), not getBrowserMedia(). The browser negotiates
between the app and the user, not the app and the machine.
But enough hippie stuff...
WHICH WAY GIVES YOU ACCESS TO THE USER'S NOSEBLEED5000 3D CAMERA MOST OFTEN?
A) getUserMedia({ mandatory: { 3D: true } }, success, fail);-> Firefox
28: ConstraintNotSatisfiedError
Firefox 29: 3D
B) getUserMedia({ optional: [{ 3D: true }]}, success, fail); -> Firefox
28: something
Firefox 29: 3D
It's B, because the user wants this to work, and will try to pick the
right camera when his browser and/or camera driver are clueless.
Reaction card (check one):
[ ] But he may pick the wrong thing!! Burn! 404!
[ ] Let him play. The goal is not to control, but to make the
experience work seamlessly or work.
So why not:
C) getUserMedia({ mandatory: { 3D: true } }, success, fail);-> Firefox
28: something
Firefox 29: 3D
Because Firefox 28 doesn't know it's NOT a 3D camera...
C is better than B, because it wont list irrelevant cameras in Firefox 29.
.: Jan-Ivar :.
Received on Thursday, 14 November 2013 10:36:45 UTC