Re: Early Holiday Present: Settings API version 6

On 2012-12-12 20:01, Travis Leithead wrote:
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html
>
> This is the original (v5.1) planned revision of the settings v5 proposal, due 2 weeks from our last telecom. It contained enough substantial changes that I bumped the planned version number.
>
> Please read the definitions section (2) which sets out some of the terminology and concepts that will make the rest of the document far easier to understand.
>
> (Brief) Summary of Updates:
> * Martin's proposal for getting the list of device identifiers (sourceIds) is included
> * Bakes in concepts from Martin's synchronous gUM Option 3, notably:
>    - Tracks can take constraints in their constructors
> * "Settings" are now split into capabilities and constraints (there is no more "settings" concept)
> * Further simplified the "source" model from prior proposals
> * Added a concept of "read-only" sources to better allow for either file-backed sources or readonly device-sharing (born from EKR's comments in the telecom).
>
> -Travis
>


I think this look pretty good and I wouldn't object to putting it into 
the spec.

Here's some feedback (I haven't had time to read previous feedback so I 
apologize if I've repeated something already noted.)

 > Sources that must have an identifier are camera and microphone sources;
local file sources are not required to have an identifier. Source
identifiers let the application save, identify the availability of, and
directly request specific sources.

In previous discussions we've talked about that applications shouldn't 
be able to detect if a user has selected a file instead of a "real" 
device. Can we maintain that feature with this proposal?


 > interface MediaStreamTrack : EventTarget {
              attribute DOMString           id;

id should be readonly.


 > Provides a mechanism for developers to assign and read-back the 
identify this track and to reference it using MediaStream's 
getTrackById. (This is a preliminary definition, but is expected in the 
latest editor's draft soon.)

It's been added.


 > Enumeration description
new	The track type is new and has not been initialized (connected to a 
source of any kind). This state implies that the track's label will be 
the empty string.

s/label/sourceId/ ?


 > sourceId of type DOMString, readonly
     The application-unique identifier for this source. The same 
identifier must be valid between sessions of this application, but must 
also be different for other applications. Some sort of GUID is 
recommended for the identifier.

s/this source/the source that is providing this track with data/

It also needs to have a value (null or ""?) when sourceType is "none".


 > interface VideoStreamTrack : MediaStreamTrack {
     static sequence<DOMString> getSourceIds ();

I know we've talked about having this functionality on a global object 
(e.g. navigator.userMedia-something). I'd like to see such a proposal. 
It could also be the place where we attach a listener for new devices 
(the probe example 7.8 feels a bit hackish).


 >  If the sourceType is "photo-camera", then this method temporarily 
(asynchronously) switches the source into "high resolution photo mode"

What should happen if another track is using this source for video 
conferencing at the same time?


 > enum VideoFacingModeEnum {
     "notavailable",

Could we use "not-available" instead? (for all occurrences)


 > interface MediaStreamTrackStateEvent : Event {
     readonly attribute DOMString[] states;

Do we need to handle this in such a special way? Couldn't we use a 
simple event and fire for every state change. That how it normally works.


 > 7.2 Getting access to a specific video source (if available)
VideoStreamTrack.getSourceIds().forEach(...

This example could be simplified a bit with indexOf() to see if the old 
id exists.


/Adam

Received on Monday, 17 December 2012 16:08:06 UTC