RE: Select function (Re: V4 comments (Re: Settings API Proposal v3 feedback summary))

> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> 
> One piece I missed in the previous round:
> 
> MediaDeviceList.select says:
> 
> Apply a set of optional and/or manditory constraints to the set of
> devices in the device list, with the goal of selecting a single device.
> This will queue a task to fire either a "constrainterror" or
> "constraintsuccess" event depending on the result. The
> "constraintsuccess" event includes the selected device on the
> DeviceEvent object's device attribute.
> 
> What this does not say is what the result of selecting a device is. Will
> it replace an existing device in some mediastream, be added to the
> mediastream, or does something else happen?

Good question. In fact, I had imagined that select() would have zero impact
on any MediaStreamTrack in the device list. What it does, is report (via
the "constraintsuccess" event) which of all the devices in the list _could_ 
support the given constraints, but it does not "configure" the resulting
device in the same way that getUserMedia does. It is then up to the application
to substitute the selected track for another one in a MediaStream, or to 
enable/disable it, etc. Less magic is better here in my opinion.

I've updated the proposal to make this more clear.


> If the user wishes to start using two cameras from the device list, how
> is this to be done?

They have to manually add the device track from the device list into a new
or existing MediaStream via the MediaStreamTrackList.add API.


> (Parenthesis: any time I see "any" as a return value, I wince. Can we
> constrain this to types that make sense?)

Me too. However, this is a limitation in ReSpec (which I'm using for ease of authoring).

In the proposal update noted above, I also went through and documented what the actual return 
value union types should be for the 'any' types.

Received on Friday, 5 October 2012 22:21:26 UTC