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

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.:

```js
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 
https://github.com/w3c/mediacapture-main/issues/394#issuecomment-247656374
 using your GitHub account

Received on Friday, 16 September 2016 17:15:57 UTC