Re: Missing definitions for parameters in MediaTrackCapabilties/MediaTrackConstraints?

Den 21. april 2015 21:23, skrev Jan-Ivar Bruaroey:
> On 4/20/15 2:42 PM, Harald Alvestrand wrote:
>> On 04/20/2015 07:53 PM, Martin Thomson wrote:
>>> On 20 April 2015 at 05:40, Harald Alvestrand <harald@alvestrand.no>
>>> wrote:
>>>> There's more text on what they mean in section 14.1, "Track
>>>> Constrainable Property Registration".
>>> Can we remove the registry?  Is there any reason that we can't simply
>>> maintain the document with the definitions of the things we are using?
> 
> +1 on removing.
> 
>> Only if we want to subscribe to the "living standard" hypothesis, and to
>> the hypothesis that the W3C WG is the only body that will ever want to
>> register a constraint.
>>
>> Not saying that we need to make one or the other decision, but trying to
>> make sure we all agree to the consequences of the decision.
> 
> How does having a registry prevent all that? It seems incumbent on any
> new spec (from w3c or elsewhere) extending the mediaStream API, to
> document new constraints and to do so in WebIDL (with partial dictionary
> etc).

My take - others might differ:

When NewBrowser 53 has determined that it needs a parameter, it's going
to ship with that parameter.

If it can't get it into the place where parameters are registered, it
will ship without registering it.

If there's a registry that ensures that it can get the parameter
registered within a week or two, even if the name should have been
"ohmygodiwishididnothavetodothisbutireallyhaveto", it might register the
parameter.

If the process involves an undetermined length of negotiation with an
undetermined set of people in order to determine whether the constraint
should have one or two occurences of "really", it will simply ship.

> 
> If it became impossible to define new constraints without writing a spec
> documenting them, then that seems like a good thing to me.

There's absolutely nothing that this WG can do to prevent people from
writing new constraints in code and shipping the result.

The thing we can definitely influence by decisions we take is how easy
it is to share documentation of what's shipping.

(We can also try to influence the community and push them towards having
well thought out constraints that have consensus behind them instead of
ad-hoc constraints. That's a Good Thing. But we shouldn't mistake that
desire to influence for an ability to control.)

Received on Thursday, 23 April 2015 09:45:00 UTC