- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Tue, 9 Oct 2012 16:00:39 +0000
- To: Travis Leithead <Travis.Leithead@microsoft.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
I prefer the constraints approach for setting and the statistics approach for reading the current settings. I'll wait see the notes from the call as I won't be able to make the call but this seems like it would need to add a lot of the things you don't want to add to make it meet the use case we discussed long ago. On Oct 2, 2012, at 18:10 , Travis Leithead <Travis.Leithead@microsoft.com> wrote: > V4 is now ready. I've posted it on Mercurial for easier reading: > > http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v4.html > > Thanks! Looking forward to your continued feedback. > > >> -----Original Message----- >> From: Travis Leithead >> Sent: Monday, October 1, 2012 4:37 PM >> To: public-media-capture@w3.org >> Subject: Settings API Proposal v3 feedback summary >> >> Before preparing the 4th version of the settings API proposal, I thought >> it would be nice to step back and summarize the feedback received on v3. >> I've not been as responsive to responding to individual threads, so I'm >> using this one as an opportunity to aggregate all the feedback into one >> location. >> >> There was lots of positive responses. Thank you! >> >> I have a v4 that I'll be releasing shortly, so stay tuned. >> >> -Travis >> >> 1 Liked the approach/heading in the right direction [Rich-2] [Stefan-1] >> [Adam-1] >> 2 Are all the various dictionaries values read/write or read-only? >> [Stefan-1] >> 3 Should the constraints/settings be inlined in the spec? (No strong >> preference) [Stefan-1] >> 4 Is this proposal and constraints applied to gUM complimentary? [Stefan- >> 1] >> 5 Establishes a nice "source-of-track" pointer [Randell-1] >> 6 Derivative of an earlier proposal (suggested in [Randell-2]?) >> 7 Doesn't solve multiple consumers competing for changing settings >> [Randell-1] (clarified by [Stefan-2/3]) >> 8 Forces all tracks that want changes to have a MediaDevice >> (PeerConnection, Video element src) [Randell-1] [Stefan-2] >> 9 Proposal for unified device/track concept (duck-typing) [Rich-2] >> (comments [Travis-2]) >> 10 Liked the prior proposal with immutable track lists over the devices- >> based LMS [Adam-1] [Adam-3] >> 11 takePicture(); how is it related to regular media stream recording? >> [Adam-1] >> 12 Can the *Info dictionaries be exposed to gUM for early device >> filtering? [Adam-1] >> 13 Should align with PeerConnection track ideas/ track-subtypes [Adam-2] >> 14 Additional settings requested [Giridhar-1] >> 15 Proposal on how to scope what settings we expose [Rich-1] >> 16 Idea on how to consolidate/group the settings [Josh-1/2] [Jim-1] >> [Travis-1] >> 17 How do we define interoperable settings (how do we test them)? >> [Frederick-1] [Jim-2] >> 18 How should UA's optionally surface device-specific settings? [Jim-2] >> 19 Re-consider one track-per-type in gUM? [Adam-3] >> 20 Don't hide capabilities behind get/changeSettings APIs [Rich-2] >> (comments [Travis-2]) >> >> [Stefan-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0000.html >> [Stefan-2] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0002.html >> [Stefan-3] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0003.html >> [Randell-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0001.html >> [Randell-2] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Aug/0044.html >> [Adam-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0004.html >> [Adam-2] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0006.html >> [Adam-3] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0005.html >> [Giridhar-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0008.html >> [Rich-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0013.html >> [Rich-2] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Aug/0144.html >> [Josh-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0017.html >> [Josh-2] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0020.html >> [Jim-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0018.html >> [Jim-2] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0022.html >> [Travis-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0019.html >> [Travis-2] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Aug/0146.html >> [Frederick-1] http://lists.w3.org/Archives/Public/public-media- >> capture/2012Sep/0021.html >> >> Additionally, I'm thinking about the following: >> * How often will settings be changed in bulk vs. one-at-a-time (with user >> feedback)? >> * How will developers know to request another device via gUM? (how will >> they know that more devices are available)? > >
Received on Tuesday, 9 October 2012 16:01:12 UTC