Re: Bare constraint values - KISS

On 7/9/14 7:22 AM, Stefan Håkansson LK wrote:
> On 09/07/14 07:21, Jan-Ivar Bruaroey wrote:
>> At the interim, we decided that plain constraint values should be
>> optional, not required, which means the "camera" default fails to
>> produce "just cameras", and we get a mix of screensharing sources
>> and cameras returned.
>>
>> This is a red flag to me on syntax. Having defaults be used in this
>> way to segregate mutually exclusive sets seems useful and nicely
>> orthogonal to everything else.
> To help me understand: this problem surfaced due to the proposed way to
> specify screen/app sharing?

Yes. Using constraints to pick between mutually-exclusive pools of 
sources (cameras vs. screens) doesn't work with bare-values-mean-ideal 
(because screensharing sources would leak into camera lists of existing 
users).

> Could an alternative be to change that instead?

Sure, it just seems intuitive to use constraints for selection - which 
this is - and it seems limiting that it cannot be used this way ever. If 
we sacrifice this ability, lets make sure we do it for good reasons.  
FWIW both Firefox and Chrome use constraints right now to specify 
screensharing.

Full disclosure: I've disliked bare-values-mean-ideal since the interim 
for their semantic complexity and unintuitiveness, so adding this issue 
to the pile of concerns with it is affirming to me that we're better off 
with a plainer syntax that can be leveraged this way.

> (I'm not really opposed to your proposal. I have a small problem with
> the fact that if the app does not check - which it should - if a certain
> constraint is understood by the UA or not it would mean that up to the
> day the UA implements it it would be ignored, but the day it is
> understood it would be required. That is a footgun to me.

That's true already, and would be true for any dictionary-based setting, 
constraint or otherwise, so your concern seems orthogonal to the issue 
at hand.

As a constraint we'd be able to take advantage of the 
getSupportedConstraints API we already have to determine support. As a 
dictionary setting, we'd have to invent something similar.

> But my main concern is that leaving the consensus of the Interim meeting
>   - even if in small steps - could leave us with no consensus at all.)

That would be terrible. I hope everyone sees that discussing what bare 
values should mean is akin to discussing which behavior should be the 
default and why it is better than the other way around. I think we 
should be able to do that without pulling into question the behaviors 
themselves. Hopefully a moratorium on further discussion is not needed, 
as there didn't seem to be that much time allotted between "lets just 
get the consensus down first" to "now discuss!"

.: Jan-Ivar :.

Received on Wednesday, 9 July 2014 18:03:01 UTC