- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Mon, 1 Oct 2012 23:37:17 +0000
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
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 Monday, 1 October 2012 23:40:47 UTC