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

Re: Direction: Constraints

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 15 May 2012 12:38:39 +0200
Message-ID: <4FB2322F.6030102@alvestrand.no>
To: Rich Tibbett <richt@opera.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
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.

> 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.

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).

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

Received on Tuesday, 15 May 2012 10:39:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:09 UTC