RE: Do we need a powerNetworkFrequency constraint?

Note that the group had considered this constraint very early on and rejected it - this topic was covered in https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html as 'antiFlicker' and the reason for rejection is stated.  If we are to consider adding this constraint to the spec as part of Last Call, in my opinion we would be revisiting a group decision.  If that is the case, one could argue that we as a group should revisit more common camera settings that would also be desirable for MediaStreams.  

This would also be a mess (my opinion of course).  For instance, the spec that I am editing (ImageCapture) provides several settings that are also not currently part of the MediaStream constraints.  If they get moved to the MediaStream at this point, then the ImageCapture spec will have to undergo significant changes.  Maybe one could argue that this is the right thing to do - if a spec needs to be revised then roll up your sleeves and revise.  But given that we don't know what other constraints may be proposed in the future that involve revisiting group decisions, I think this will complicate finalizing the dependent specifications coming from this group

I will suggest the following at this current stage:

a) Do not add new constraints to the LC spec
b) Address only new constraints proposals for inclusion in the MediaStream constraints registry that are not covered in other MediaCapture specifications
c) Continue to develop the process for adding constraints to the registry and consider new constraints under such a process

-Giri

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Tuesday, August 25, 2015 11:35 AM
To: Adam Roach; public-media-capture@w3.org
Subject: Re: Do we need a powerNetworkFrequency constraint?

Den 25. aug. 2015 18:47, skrev Adam Roach:
> On 8/25/15 00:47, Harald Alvestrand wrote:
>> powerNetworkFrequency = "50Hz", "60Hz", "default"
>>
>> ...
>>
>> What do people think?
>>
> 
> Do you mean that we want to add this in general, or in the initial 
> version of the spec?
> 
> In general, it seems like a good sort of thing to have.
> 
> If you mean in the first version of the spec, then I'm getting a 
> little confused about the nature of the "feature freeze" that people 
> seem to be selectively invoking. gUM constraints are extensible, 
> easily discoverable, and intended to be registered at a later date. 
> This is kind of the poster child for something that can be easily 
> added on after the initial spec is published.



I think this is a poster child for the idea that desirable constraints will pop up over time, and we need a process to handle them.

I should have said on my initial post - this is me with my Google implementor team hat on, saying "we need to do something like this, can we all agree that this is an OK way to do it?" - my chair hat is desperately looking for a clue-by-4 to beat my Google hat over the head with saying "what part of "feature freeze" don't you understand?"....

We might want to deflect the "how do we register it" to the (too quiet!) thread called "Requirements for constraints maintenance" - if we all agreed how we intend to handle requests for new constraints, we might have less of a panic when a new idea for one comes up.

But what I (with my Googler hat on) am looking for is first of all "is this a good thing to do?" and second "if we do it, is this (in detail) an OK way to do it?"

Harald

Received on Wednesday, 26 August 2015 13:49:26 UTC