- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 18 Mar 2014 15:06:49 +0100
- To: public-media-capture@w3.org
On 03/17/2014 05:20 PM, Jan-Ivar Bruaroey wrote: > On 3/17/14 2:33 AM, Stefan Håkansson LK wrote: >> On 2014-03-15 23:29, Martin Thomson wrote: >>> On 14 March 2014 16:24, Cullen Jennings <fluffy@iii.ca> wrote: >>>> Two optional constrains, the first one saying the source is A and >>>> the second one saying the source is B. >>> Or you could try this: >>> >>> navigator.getUserMedia({ 'sourceId': 'A' }, success, function() { >>> navigator.getUserMedia({ 'sourceId': 'B' }, success, failure); >>> }); >> Hm. Would you not need to push in a "require: 'sourdeId'" in the first >> gUM? Otherwise it would be "prefer" and if treated like optional mean >> that gUM would succeed even if it could not be satisfied. > > Correct, things are optional by default, so it would be: > > navigator.getUserMedia({ sourceId: 'A', require: 'sourceId' }, succ, > function(){ > navigator.getUserMedia({ sourceId: 'B' }, succ, failure); > }); > > >>> It seems like the example is basically contrived, so why not incur the >>> additional user prompt? > > Yes, it is hard to judge what's acceptable when we don't root things > in real use-cases. > > SourceId strikes me as the "anti-constraint", i.e. how one subverts > the normal process, so we should perhaps not design the normal process > around it? > I think it works well as a constraint - sometimes you definitely want a specific source, sometimes you would prefer one but can live with anything, sometimes you just want the system to pick one. Jan-Ivar, if you think of it as an anti-constraint, then perhaps it's because you and I have a different view of how constraints work.....
Received on Tuesday, 18 March 2014 14:07:22 UTC