Re: Proposal for device "enumeration"

On 2012-12-07 18:43, Travis Leithead wrote:
>> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
>>
>> On 2012-12-06 18:57, Martin Thomson wrote:
>>> As discussed on the call, and as no doubt Travis is already typing up,
>>> here is what I think we need for device enumeration:
>>>
>>> VideoStreamSource and AudioStreamSource each have a static method
>>> (invoked on the constructor, not an instance) that produces a sequence
>>> of device identifiers.
>>>
>>>     typedef DOMString DeviceId;
>>>     partial interface VideoStreamSource {
>>>       static sequence<DeviceId> getDeviceIds();
>>>     }
>>>     partial interface AudioStreamSource {
>>>       static sequence<DeviceId> getDeviceIds();
>>>     }
>>
>> Is the gain of enumerating the deviceIds that high that it's worth the
>> finger printing surface?
>>
>> Couldn't you solve the use case of requesting a specific specific camera
>> (you have used before and know works) by only exposing the deviceId on
>> that source and having a constraint to request that particular device
>> again with getUserMedia()? The app could create and persist something
>> similar to getDeviceIds() (above) itself, but only with ids of devices
>> it has been granted access to. The latter could be a rule for the native
>>    getDeviceIds() functions as well, but it complicates things a bit.
>
>

> Let me throw out my idea for how I'd like to write this up in the
> next settings proposal draft.
>
> Instead of a deviceId, I want to use a deviceIndex (I'll call it
> sourceIndex). This meets most use cases except those in which an
> application wants to be able to detect a specific camera AND the user
> has multiple cameras that are not (or rarely) connected to the UA
> (the plug-in style of cameras/mics). Otherwise, as long as the UA
> places sources into an ordered list consistently (for the known
> device sources), and sources in this list are guaranteed not to have
> their index changed as long as the app is running (even if other
> devices are unplugged), and that new devices added during the
> lifetime of the app are added to the end of the list, then an app can
> generally rely on a source index just as well as a device identifier.
> When you get an actual source, you'll also be able to read what its
> sourceIndex is, as this will be just another setting. I'll keep the
> getNumDevices() API so that an app can know how many sources there
> are before requesting.
>
> I think this is far easier to spec, less prone to fingerprinting, and
> maintains almost all of the important use-cases. As previously noted,
> if devices don't come and go frequently (which I assume to be the
> case for most devices with embedded microphones/cameras), then apps
> can reliable cache the last known index of a device they want to
> request next time, and simply request it.
>
> For requesting a previously identified source, you apply the
> constraint:
>
> New VideoStreamTrack({ optional: [ { deviceIndex: 0 } ] }); // or
> mandatory, if you must have it, but this isn't advised as the
> identity of the device at index 0 _can_ change between invocations of
> the app.
>
> Through the new settings API you will be able to use this new
> constraint to change sources for a track.

I think getNumDevices() + sourceIndexes (on granted devices) would work 
equally good as getNumDevices() + deviceIds (on granted devices) which I 
proposed earlier to Martin.

/Adam

Received on Monday, 10 December 2012 07:00:42 UTC