Re: Why ignoring unknown mandatory constraints is not stupid

On 19/11/13 16:56, Jan-Ivar Bruaroey wrote:
> On 11/19/13 4:29 AM, Stefan Håkansson LK wrote:
>> On 18/11/13 21:57, Harald Alvestrand wrote:
>>> But I think I'll stop posting on this subject. Let's hear from
>>> others.
>> Well, as you asked for it:
>>
>> On the topic of gUM failing or not on unknown mandatory
>> constraints
>> ===================================================================
>>
>>
I come to the same conclusion as Harald. If we take the example of
>> "zoom" (which seems the one just outside mandatory-to-support
>> according to slide 24 in
>> http://www.w3.org/wiki/images/f/fd/Constraints20130406.pdf): Assume
>> my app for some reason must be able to control zoom (so it puts it
>> as a mandatory constraint for gUM). If the browser doesn't
>> understand "zoom", I am not helped by a success CB because the
>> browser can't control the zoom - and that was a mandatory
>> requirement for me.
>>
>> On getSupportedConstraints ========================== This is a
>> really good proposal I think, we should introduce (something like)
>> this.
>
> Problem followed by remedy.
>
> Your example uses gUM constraints to infer whether a browser supports
> zoom, just like Harald's did for thermal. That's exactly what
> getSupportedConstraints() solves. I hope you agree you should call
> that to learn what the browser supports and doesn't support. It is a
> much simpler question to answer that doesn't need to involve gUM or
> the risk of arousing a user permission prompt at all.

Yes, I agree, and we should introduce getSupportedConstraints() IMO.

>
> As Adam pointed out, we should not assume that every constraint will
> be useless without browser support. "zoomOnFaces" would presumably
> not require browser support.

But if we want the app to be able to control (turn "zoomOnFaces" on or 
off), surely it would need browser support?

>
> No matter how many turn out to be of one kind or the other, asking
> directly is a better API anyway because now the app has better
> information, and we can discuss fixing things so people can use
> mandatory constraints for new constraints much sooner than they
> otherwise would without risk of blocking legitimate sources in the
> cases where we're not certain the app wishes shutoff in the unknown
> case. Let the programmer turn it off explicitly, then people can yell
> at the programmer.
>
> We've seen many examples of invariants, and not so many on false
> negatives, so let me offer one:
>
> Our gUM constraint skeleton is riding the Firefox Aurora train right
> now, but with almost no constraints implemented (facingMode being the
> lone one). Pause and think about that.
>
> As a result, anyone using mandatory for ANYTHING is going to be
> extremely sad, because their app will stop working on Firefox. We
> know the group of programmers affected is not zero, because we are
> already hearing from them:
> https://bugzilla.mozilla.org/show_bug.cgi?id=927358
>
> Sure you can pick at this example, and say the programmer thought
> these were MTI, but A) that hasn't been clear until extremely
> recently, and B) I might equally argue these programmers thought they
> could describe their needs in relation to cameras, without having to
> consider that the old-browser case would produce complaints from
> valid users.
>
> Even if you disagree about blame in this example, you cannot refute
> that this is exactly how it will go down in the future when something
> works in one browser and not another.
>
> When I program something in JS, here's how I, nay I claim everyone,
> thinks:
>
> Does it work in Firefox or Chrome? Yes = Blame that browser, not my
> app.

This may well be true.

But the whole question revolves around the term "mandatory". It has been 
said over and over that "mandatory" should _only_ be used if the app 
developer prefers to not offer the service over not being able to 
fulfill this requirement. So I am sort of lost on the reasoning saying 
you should back off - if you're willing to back off from a mandatory 
constraint it should have been optional in the first place. Or am I 
missing something?

If it is not really possible to get app developers to agree, and they 
will insist using mandatory constraints for things that are optional, 
then we have a problem, I would agree to that.

>
> I agree that ensuring a nice UX is great if you can avoid breaking
> people.
>
>> Would it make sense to go with only optional constraints for the
>> first version?
>
> See, now how is that preferable to what I'm proposing?
>
> .: Jan-Ivar :.
>
>

Received on Tuesday, 19 November 2013 18:04:32 UTC