Re: Capabilities API proposal

On Jan 25, 2012, at 2:50 AM, Harald Alvestrand wrote:

> On 01/24/2012 09:59 PM, Randell Jesup wrote:
>>> This led us to propose that 1) the return from getCapabilities() should be a collection of profiles/configurations that the browser is capable of providing, and that 2) the input to the Hints API should be an author-ordered subset of these configurations.  While it does not guarantee in advance which configuration the author will get, it does guarantee that if an acceptable configuration can be provided it will be, without having to try, fail, try again, fail again, etc.
>> 
>> A problem I see with this is a combinatorial problem: if getCapabilities returns the "collection of profiles/configurations the browser is capable of providing", then when you add multiple devices (multiple mics, multiple cameras, etc) the set of options becomes quite large, and selecting from it becomes more involved.  I'm not saying impossible, but the added complexity for the typical application (and how likely they are to test it properly against possible capabilities) worries me a bit.
> Possibly naive implementations will be written to the pattern of
> 
> getCapabilities({video=on, audio=on}, capsEventCallback)
> 
> capsEventCallback(caps) {
>   if (caps) {
>       getUserMedia(caps)
>   } else {
>       error("No permissions granted")
>   }
> }
> 
> that is, the naive version is "just grab the first thing the user is willing to grant me".
> It's then up to UA implementation quality to actually return something sensible in its first option.
> 
This is a very good point.  I'm strongly of the belief that we need to make the simple easy and the complex possible.  Thus, if someone just wants "video and audio" they can make a call as you suggest.  As long as it is possible, if ugly, to do something more sophisticated, I think it will satisfy the above maxim.

Received on Wednesday, 25 January 2012 13:43:56 UTC