Re: Direction: Constraints

Harald Alvestrand wrote:
> On 05/15/2012 11:46 AM, Rich Tibbett wrote:
>>
>>
>> Harald Alvestrand wrote:
>>> Given the debates we've had about the constraints/capabilities
>>> functionality, the
>>> clear need many see for it, and the proposal that Dan Burnett posted
>>> to the mailing list on April 23 and the debate that has followed it,
>>> the Chairs declare that we have a reasonable consensus that moving
>>> forward with this specification is the right thing to do.
>>>
>>> The chairs are therefore asking the editors to incorporate this
>>> proposal in the current documents.
>>>
>>> Of course, suggestions for improvements to this API are always welcome.
>>
>> Opera cannot integrate this in to our current products since we are
>> not yet pursuing a trusted environment model for the web on which this
>> proposal heavily relies. The upshot of this is that we will not be
>> able to claim conformance to the getUserMedia specification if this is
>> added. This and the fact that there is a lot of hidden complexity and
>> a lot of unresolved issues in this proposal is likely to significantly
>> delay delivery of the core getUserMedia specification in the standards
>> process.
> As far as I have understood, the features that rely on a trusted
> environment are the capabilities features, not the constraints features.
> While the capabilities give an easy source of hints for what constraints
> might be worth specifying, I do not believe they are mandatory for using
> getUserMedia with constraints.

Constraints without capabilities seems like it would be more 
hit-and-miss than implementing the two concepts together. It would be a 
bit like trying to simply guess on some constraints to request without 
knowing the parameter ranges we can play in. Since we can't implement 
capabilities then it would be preferable if we also didn't do 
constraints until a time when it is possible.

>
>>
>> It would be preferable if trusted environment features are pursued in
>> a separate specifcation for now and the open issues on this proposal,
>> of which there are many, are pursued orthogonally to the main task of
>> nailing down the core features of the getUserMedia specification.
>
> So far, the suggestion is to add the mechanism and syntax for the
> constraints to the specification, and not add the actual constraint
> definitions to the specification yet.

It's highly unusual to put placeholder API stubs in a standard for 
potential future features. We should make provisions for future features 
in the spec (e.g. make sure API objects/arguments/attributes provide an 
extensible structure where necessary) but not put any placeholder 
structures in until we're ready to specify the actual solution with it. 
We'll define actual solutions at that future time given all of the 
information and dev/user experience available at that moment to inform 
our final solution.

>
> I believe the largest areas of open issues are in the definitions of the
> constraints; it should be possible to claim conformance to the
> getUserMedia specification without actually implementing support for any
> constraint apart from "must have video" and "must have audio" (and even
> those seem to have a special syntax in the current proposals).

This would require that actual constraints and their values are marked 
as optional in the getUserMedia specification. I don't think that is the 
objective here. If they are implemented you want to be able to rely on a 
consistent set of constraints being available. Hence the proposal to 
work on this separately from the main getUserMedia core but then use 
that separate spec to make the constraints defined therein mandatory 
while still allowing them to be independently implementable subsequent 
to an initial implementation of the core getUserMedia API.

>
> So I'm not sure what parts are available for "pursuing orthogonally"
> that aren't already separate.

I believe constraints and capabilities belong together in a separate, 
independently implementable specification. That doesn't assume trusted 
environments which don't exist in the definition of the web we have 
today, doesn't confuse these features as optional additions in the 
getUserMedia specification and allows us to approach implementation in a 
phased way (e.g. we should consider constraints and capabilities 
'getUserMedia - Level 2').

Received on Tuesday, 15 May 2012 13:05:59 UTC