Re: Bare constraint values - KISS

On 10/07/14 15:25, Jan-Ivar Bruaroey wrote:
> On 7/10/14 4:20 AM, Stefan Håkansson LK wrote:
>> 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.
>
> Then why did we call it 'audio' and 'video' rather than 'microphone' and
> 'camera'?

It's a long time ago, and I don't remember. But speculating, one reason 
can have been that for a long time the thinking was that the user should 
be allowed to pick a file (or files) instead of a microphone or camera. 
A reason was that a user should not be locked out of services just for 
the reason of not having e.g. a camera. That is history now, but could 
be a reason why we call it video instead of camera.

>
>>> 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 agree about the confusion, but I think this largely started with the
> ideal/exact default inversion. That inversion was motivated by utility,
> at the cost of confusion. The opposite is extremely simple, if unclear
> because of all the legacy. We could rename 'advanced' back to
> 'optional', which might help underscore that mandatory has just been
> hoisted one level up.
>
>> 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.
>
> But you'd get the wrong thing instead. For things like aspect and
> facingMode, this may not be desirable. I think we're mixing web
> developer and end-user here. Yes, gum fails, but that's for the web
> developer to deal with, and they may try again with different
> constraints. Only if the web developer did a poor job would the symptoms
> you mention follow, and the best way to ensure that the developer does
> it right is to make the syntax as simple to understand and as
> predictable as possible. I too have had concerns about mandatory in the
> past, and I share your concern a little bit, but I think these
> particular training-wheels get in the way of driving.

As I said in my first response: this part is really only a minor concern 
for me and perhaps I should not have brought it up at all. (But I can't 
escape the feeling that we've gone full circle on this: did you not 
introduce the mandatory/footgun problem originally?)

I think however that we should treat screen/application sharing as other 
media types than camera video in the interest of getting done with the 
latter without having it be on hold until we understand the former fully.

Stefan

Received on Friday, 11 July 2014 08:07:38 UTC