W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2012

Re: Settings API Proposal v3 feedback summary

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>
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11188136F@xmb-aln-x02.cisco.com>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:02 GMT