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

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