W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2016

Re: How to handle known but irrelevant costraints (Re: How to handle known but unsupported constraints)

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 6 Jan 2016 07:24:16 +1100
Message-ID: <CAHp8n2k+4MZViTotu-Fc=PrezSgKLYNL5eOwf+bmRgO9cVX-Rw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-media-capture@w3.org
Hmm, the web platform is typically generous in ignoring things that are
surplus. In this case though it's a coding error, because it's a required
constraint that will always fail, so should be discoverable during coding
time. I could live with either approach.

Best Regards,
On 5 Jan 2016 11:04 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

> This is a riff on Adam's issue about known but unsupported constraints:
> What's the expected behavior for constraints that are simply not
> relevant to the case at hand?
> I'm thinking, for instance, of:
> getUserMedia({video: { echoCancellation: {exact: true}}})
> echoCancellation is a known and supported constraint, but for video,
> it's just not there - and the user is asking for a failure if it can't
> be applied.
> Is the correct response to return a promise resolved to an
> "overconstrainedError" with the "constraint" field set to
> "echoCancellation"?
> This is what is implied by the current text for "fitness distance":
> "If the constraint is required ('min', 'max', or 'exact'), and the
> settings dictionary's value for the constraint does not satisfy the
> constraint, the fitness distance is positive infinity."
> I'm pretty confident that's what the spec says now, but I want to make
> sure we're all agreed that this is what we intended.
> Harald
Received on Tuesday, 5 January 2016 20:24:46 UTC

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