- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Fri, 22 Nov 2013 10:48:30 -0500
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 11/22/13 4:23 AM, Adam Bergkvist wrote: > Even with applyConstraints() you might still want express something as > an acceptable range and then check the setting what you're actually > getting. Also, even though the applyConstraints() call succeeded, > there might be changing circumstances that prevents the UA from living > up to the developers wishes. The constraint concept has a way to deal > with that. You're the one who wanted to leave out optional here. :-) Thanks for clarifying. I think I understand now. Min/max ranges, when used with track.applyConstraints(), leave wiggle-room for a browser or device to pick its preferred value or even vary the value over time if they need to. Sounds useful. Can we please spell that out in the spec? This is subtly different from gUM() which is picking from mutually exclusive sets of capabilities, and I now appreciate the symmetry of why we shouldn't overload min/max with "give me highest/lowest in range" there (because the overload is taken), which wasn't obvious to me before. To answer your earlier question, you definitely want optional in there then, since optional expresses preference, just like ranges do. .: Jan-Ivar :.
Received on Friday, 22 November 2013 15:48:58 UTC