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

Re: [mediacapture-main] Browser's ability to dynamically change settings mistakenly removed

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Fri, 16 Sep 2016 17:15:42 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-247656374-1474046139-sysbot+gh@w3.org>
Perhaps I misunderstood. I interpreted @burnburn's request as wanting 
to restore the UAs ability to change a source within the envelope of 
existing constraints on it. If so, this would never throw 
`OverconstrainedError`. @burnburn is that what you meant?

@alvestrand With "external environment changes" you mean e.g. lighting
 effects on `frameRate`?

If so, then yes, fire `OverconstrainedEvent` in that case, but I don't
 think we should lump that together with "other requests". I'd expect 
new requests to fail rather than succeed and fire 
`OverconstrainedEvent` on other tracks of the same source, as that 
seems consistent with *SelectSettings* dictating that 
`applyConstraints` must leave things alone when it fails. E.g.:

let clone = track.clone();
track.applyConstraints(tougherConstraints); // can fail, but can't 
overconstrain clone

(Conflicts are easier to imagine in browsers that don't add "virtual" 
settings through rescaling.)

Unfortunately, *SelectSettings* does not address existing constraints 
from other requests, though I saw just two ways to extrapolate how it 
should work, and having new concurrent requests fail rather than 
having them impact existing requests, seemed most consistent with 
`applyConstraints` leaving existing settings alone.

I basically interpret settings dictionaries that conflict with 
existing constraints from other requests to be impossible in the 
sentence "every possible settings dictionary".

Does that match everyone's expectation?

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at 
 using your GitHub account
Received on Friday, 16 September 2016 17:15:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:30 UTC