W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2014

Re: Capabilities vs SupportedConstraints

From: Rob Manson <roBman@buildAR.com>
Date: Sun, 02 Nov 2014 18:54:51 +1100
Message-ID: <5455E34B.5060004@buildAR.com>
To: public-media-capture@w3.org
Hi Jan-Ivar,

> What if we renamed  MediaTrackConstraintSet (mouthful) to
 > MediaCapabilities?

+1


> After all, we're constraining  in the capability space.

+1


> Doing so would have several  benefits as I see it:
 >
 > 1. getCapabilities() would return MediaCapabilities, which seems
 > right [1].

+1


 > 2. We avoid silly questions like "is volume a constraint?", when the
 > right question is "is volume an available capability?"

Yeah...the language to me seems like it would be "If I change my 
Constraint upon the volume Capability what Setting will I end up with?"


> As for what  SupportedConstraints() should return or be called, I
 > argue in the same PR for returning what effectively amounts to a
 > MediaCapabilities with "opaque" values. With your observation, it
 > might be interesting to explore whether it could return something
 > more detailed once permission is granted (somewhat like
 > enumerateDevices does).

+1 but then I think it could be better named 
SupportedCapabilities()...but I do get that it's about finding out what 
Constraints you can apply to turn potential Capabilities into explicit 
Settings.

roBman
Received on Sunday, 2 November 2014 07:48:18 UTC

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