Re: Bare constraint values - KISS

On 09/07/14 20:02, Jan-Ivar Bruaroey wrote:
> 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.

The original motivator for constraints was actually for selection, so 
you have a point. But then it was more about selecting the right device 
of a certain kind, e.g. the right camera (that it should be a camera was 
identified by "video"). I am not sure we should build on it to also 
select between e.g. camera and screen as source.

>
> 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've come to believe that we should remove "bare" altogether. It has a 
small convenience gain, but given the confusion it creates I doubt it is 
worth it. But I hesitate to talk about this since I don't want to break 
any consensus.)

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

Yes, but the difference is that if bare means "required" you'd be looked 
out of the service. If it means "ideal" you'd not be.

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

Good point.

>
>> 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!"

I agree.

>
> .: Jan-Ivar :.
>
>

Received on Thursday, 10 July 2014 08:21:13 UTC