- 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