Re: UserMediaSettings

On 3/13/14 5:45 AM, Harald Alvestrand wrote:
> One of the interesting things you've introduced in this proposal is 
> representing attribute names as both strings and attributes, in order 
> to implement the "require" and "prefer" methods. This is unstylish.

I think it is stylish to follow the rules here. Dictionary keys being 
inherently optional can't be used to fashion a requirement list, because 
the browser wont see requirements it doesn't know. A string survives.

It also accomplishes the stated goal from our last teleconference, which 
was to "make mandatory harder to use" (a poorly worded way of saying 
"lets avoid people falling into mandatory and its sharp 'I mean it!' 
edges by default).

> Another interesting property is that you have lost the ability to 
> propose an order in which to try alternative values for the same 
> attribute. This is a loss of functionality.

A loss in complexity that should affect no known use-cases, hence a win. 
For example, lets compare a "I prefer higher frame rates" use-case, 
first with existing constraints:

   var constraints = {
     video: {
       optional: [
         { aspectRatio: 16/9 },
         { frameRate: { min: 300 } },
         { frameRate: { min: 200 } },
         { frameRate: { min: 100 } },
         { frameRate: { min: 60 } }
       ]
     }
   };
   navigator.getUserMedia(constraints, success, failure);

Yes, that's {{[{{}}]}}, giving lisp a stylish run for its money.

With constraints, you had to put, in the optional part, the same 
parameter (e.g. frameRate) several times with gradually decreasing 
values. The number of values you had to provide seem arbitrary, but may 
in fact no be, as you have to coax the algorithm to go up instead of 
down. If a device supports a band of resolutions that are close 
together, then this may in fact not pick the highest available 
resolution. Fail.

Compare to:

   var request =
   {
     aspectRatio: 16/9,
     frameRate: { min: 60, ideal: 300 },
   };
   navigator.getUserMedia(request, success, failure);

In dictionaries, multiple entries are not allowed, so to get higher 
frame-rates, you express intent with the "ideal" key, creating an upward 
pull toward 300 hz, favoring higher frame-rates to lower ones. This 
expresses intent better than the old design's repetition of gradually 
decreasing values.

The "ideal" key also avoids overloading "min" and "max" with 
gravitational meaning, which, while never expressed, seems to confound 
many people (e.g. people assuming "if I specify max 120hz, then I should 
get 120 hz if I can, because why not?", which doesn't match my 
understanding of the current spec or what's been implemented thus far.

Let me know if you have other questions or want me to post clarifications.

.: Jan-Ivar :.

Received on Thursday, 13 March 2014 14:47:35 UTC