Re: getCapabilities() as both static and object method?

On 05/12/2014 08:13 PM, cowwoc wrote:
> On 12/05/2014 1:47 PM, Harald Alvestrand wrote:
>> On 05/12/2014 05:55 PM, cowwoc wrote:
>>> On 12/05/2014 8:54 AM, Harald Alvestrand wrote:
>>>> In the current version of the spec, we have:
>>>>
>>>> The getCapabilities() method returns the dictionary of the
>>>> capabilities that the object supports.
>>>>
>>>> This means that one must get an object before one can get
>>>> capabilities of it. This is inconvenient for some usages (deciding
>>>> what to pass to getUserMedia is the obvious one).
>>>>
>>>> Should this method also be available as a static method?
>>>>
>>>> Harald
>>>
>>> -1: I'm in favor of leaving this as an instance-only method.
>>>
>>> Gili
>>>
>> Why?
>>
>> What do you suggest as an alternate method for detecting availability
>> of capabilities before the first call to getUserMedia?
>
> Sorry, I hit submit too quickly. I was going to ask you to elaborate
> on how you saw this working for getUserMedia().
>
> Perhaps I misunderstood what you meant. My understanding was that you
> wanted classes to have both a static and instance method. If so, I
> would be -1 on that and would favor classes having either of the two
> but never both at the same time. I don't see the need for classes to
> have both and think that doing so would be confusing to developers.

I still don't understand this part - what's so especially complex about
having a method that is callable either on the class or on the instance?

The need as identified  is to know what constraints are recognized by
the platform before calling getUserMedia (that is, before we have any
instances to call the function on).
What would you suggest as an alternate approach for fulfilling that need?
Alternatively, are you suggesting that you don't think that need should
be fulfilled?

>
> On a higher level, I'm in favor of allowing developers to enumerate
> devices and their capabilities without prompting for user permission.
> I view getUserMedia() as the act of "opening" the devices I am
> interested in, which would prompt the user for permission.

I suggested a separate permission-manipulation call a few cycles back,
but that was rejected by the WG as "too complex", so all permission
manipulation is done through getUserMedia.

So stuff is either visible to the drive-by Web, or it's gated on
getUserMedia calls.

Perhaps it's time to revisit that decision?

Received on Tuesday, 13 May 2014 07:42:13 UTC