- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 10 Oct 2014 10:36:19 +0200
- To: public-media-capture@w3.org
I think Jan-Ivar's request #36 is uncontroversial, but I'd like some list discussion on #37. The important change is that we use MediaTrackConstraintSet as the return value for getCapabilities, getSettings and getSupportedConstraints. What we previously thought, and what the change means: - getCapabilities returns a constraint set that indicates "the maximum supportable values". I think using MediaTrackConstraintSet is uncontroversial here. - getSettings returns something with the same keys as a constraint set, and values of the same type as the type of the constraint set. Returning bare values in a MediaTrackConstraintSet is a bit odd (since the semantic of a bare value is "ideal" when it's passed in the other direction), but seems not too odd to me. - getSupportedContraints returned a dictionary where the keys are the same as for the constraint set, and where the values are all "true" for supported constraints (and missing for non-supported constraints, naturally). Using MediaTrackConstraintSet means that the values have to be of the corresponding types, and be "truthy" - which means that we need special treatment for constraints that have the possibility of being zero, empty string or other "falsy" things. This seems a bit iffy. Are there other ways to skin this cat? Harald On 10/09/2014 04:14 PM, bugzilla@jessica.w3.org wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=26654 > > --- Comment #3 from Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> --- > (In reply to Jan-Ivar Bruaroey [:jib] from comment #2) >> Pull request: https://github.com/w3c/mediacapture-main/pull/22 > That one has been removed. > > New PR's: https://github.com/w3c/mediacapture-main/pull/36 and > https://github.com/w3c/mediacapture-main/pull/37 >
Received on Friday, 10 October 2014 08:36:59 UTC