Re: Settings API Proposal v3 feedback summary

On 10/09/2012 06:00 PM, Cullen Jennings (fluffy) wrote:
>
> 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.

I don't think that statistics would be the right approach for reading 
the current settings. So far we have only discussed statistics in the 
context of transport over the net and in the PeerCOnnection object. So 
if we would go that way we would need to add getStatistics to the 
MediaStream object as well.

If I understand the v4 proposal correctly it does not really take away 
anything that is in the Editor's draft today, so I don't think it makes 
things any worse when meeting existing use-cases.

>
>
>
> 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 Thursday, 11 October 2012 08:08:59 UTC