RE: Early Holiday Present: Settings API version 6

Does the snapshot capability belong in the recording draft?  It sure looks like a recording/capture operation, right down to returning an event with a Blob of data.  Admittedly it works on the Track rather than Stream level, but that could be handled by having the Track be an argument to the API call.  I think it looks a little odd to have one record/capture function be a method on Track, while  all the others are in a separate class.   

- Jim

-----Original Message-----
From: Travis Leithead [mailto:travis.leithead@microsoft.com] 
Sent: Wednesday, December 12, 2012 2:02 PM
To: public-media-capture@w3.org
Subject: Early Holiday Present: Settings API version 6

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

Received on Thursday, 13 December 2012 13:42:30 UTC