Re: Do we need capabilities?

On 01/24/2012 02:51 PM, Harald Alvestrand wrote:
> On 01/24/2012 02:35 PM, Adam Bergkvist wrote:
>> On 01/24/2012 01:26 PM, Harald Alvestrand wrote:
>>> On 01/24/2012 10:18 AM, Neil Stratford wrote:
>>>> On 24/01/2012 03:04, Anant Narayanan wrote:
>>>>> (Starting as a separate thread, to document objections to
>>>>> getCapabilities)
>>>>
>>>>> 1. I think we can all agree that exposing capabilities without user
>>>>> consent of any form is not what we really want. If the current
>>>>> getCapabilities() is able to be invoked by any web page without any
>>>>> indication to the user, it is a massive privacy invasion. Ad services
>>>>> will then be able to add more bits of reliable information in order
>>>>> to personally identify visitors (they already know too much!).
>>>>
>>>> I agree, getCapabilities() does require user approval, which could
>>>> also be used to pre-approve access for a later getUserMeida() request.
>>> Hmm..... perhaps this is a place where we can recast the language of
>>> discourse....
>>>
>>> if getCapabilities() did what getUserMedia() does now, and takes
>>> parameters saying what kind of stuff it wants (audio&   video), and the
>>> user dialog gives the user the chance to select which units it wishes to
>>> expose to this application, then getUserMedia() can select freely from
>>> the devices to which it has been permitted access, and can explore the
>>> properties of devices without disturbing the user further....?
>>
>> What would be the difference to simply calling getUserMedia() as it's
>> specified today and then remove all the tracks you don't need?
> 1) Don't have to initialize those devices you intend to remove

I guess all devices needs to be initialized to show selfview (video) 
level (audio) in the selector UI anyhow. But that's up to the browser.

> 2) Don't have to get into trouble trying to reserve (say) one camera
> that's available under 2 names twice

When you say reserve here, do you mean that the browser should make sure 
that the device can be used by the browser at a later point? If so, I 
think that's actually how it would work in many cases when you create a 
stream and don't use it. The alternative is to stream media from the 
device and throw it way.

> 3) Can take "camera now, microphone later" instead of having to grab
> everything at once
> 4) Logical interface to "new device": Browser signals "I may have
> something new for you" (note - this doesn't exist yet), you call
> GetCapabilities again, user picks the new device as available to your
> app, app does the right thing - but if no change is warranted, no need
> to drop the old devices.
>
> This is off the top of my head, as was the original thought. It's
> brainstorming.
>

I think we have a quite nice model today when it comes to getting access 
to devices and revoking that access. E.g.

1. getUserMedia() -> localStream
* Indicator in browser chrome shows that the web app has access the device.
2. video.src = URL.createObjectURL(localStream);
* The ring on the physical camera lights up since it's being used.
3. video.stop();
* The ring on the camera is turned off (camera is not used).
4. localStream.stop();
* The browser indicator is turned off and the web app has to ask 
permission again to use the device.

I think the getCapabilites() approach gives the web app a bit more 
control/freedom and it might be harder to keep the model above.

/Adam

Received on Thursday, 26 January 2012 14:48:23 UTC