Re: Do we need capabilities?

On 01/26/2012 03:43 PM, Adam Bergkvist wrote:
> 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.

The situation I'm imagining is one where the browser is told there are 2 
cameras, but one is really an alias for the other; it tries to open 
both, but then gets told that the second one is busy.
I'm not sure this is a real problem; it's just happened to me when 
reserving other types of resources.
>
>> 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.

Yes, in order to get the effect of localStream.stop() above, 
getCapabilities() would have to be matched by a "releaseCapabilities" call.

The above is not completely "true", though; consider

   getUserMedia() -> localStream
   copy = new LocalMediaStream(localStream.audioTracks, 
localStream.videoTracks)
   localStream.stop()

Now, the browser indicator should still be on.


>
> /Adam
>
>

Received on Thursday, 26 January 2012 15:06:28 UTC