Re: Why ignoring unknown mandatory constraints is not stupid

On 19/11/13 14:59, Jim Barnett wrote:
> For getSupportedConstraints, we should think about the details a bit

Perhaps this should be getGumSupportedConstraints or something like that 
(bad name, what I'm after is to make it clear that it is only about the 
constraints you can use with getUserMedia).

....

> We've done enough thinking about mandatory constraints that I don't
> see any reason not to include them.  Furthermore, if we leave them
> out, what does our syntax look like?  Do we pass a constraints
> structure containing only the 'optional' item?  That will look
> strange.  Developers will expect to simply pass a list of
> constraints.  But if we let them do that, their apps will break when
> we introduce mandatory constraints.

I am not pushing for this; my gut reaction is always to "try to simplify 
when possible" and I wanted to check if this was an opportunity.

But I think that defining a syntax is not really a problem.

>
> - Jim
>
> -----Original Message----- From: Stefan Håkansson LK
> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Tuesday, November 19,
> 2013 4:30 AM To: Harald Alvestrand; public-media-capture@w3.org
> Subject: Re: Why ignoring unknown mandatory constraints is not
> stupid
>
> On 18/11/13 21:57, Harald Alvestrand wrote:
>> On 11/18/2013 09:36 PM, Jan-Ivar Bruaroey wrote:
>>> On 11/17/13 11:40 PM, Harald Alvestrand wrote:
>>>> Done: If I'm doing an application whose only purpose is
>>>> analyzing houses for isolation hotspots, getting a non-thermal
>>>> camera will just mean that I have to make code paths to deal
>>>> with "this is a camera, but the data I'm getting from it is
>>>> completely nonsensical". I don't want to spend time doing
>>>> that.
>>>
>>> I'm not saying you have to. One line is all it takes:
>>>
>>> if
>>> (!browser.getSupportedConstraints().hasOwnProperty("thermal"))
>>> return false;
>>>
>>> This is an app decision.
>>
>> By the same token, why should this developer (who write apps for
>> thermal cameras only) be the one to do that, and not the one who
>> can live with a visible-light camera when his application is
>> written for a thermal?
>>
>> The getSupportedConstraints() actually makes things a lot easier
>> when dealing with constraints that the browser may or may not know,
>> no matter whether the WG eventually agrees with me or with
>> Jan-Ivar.
>>
>> 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.
>
> On Mandatory constraints in general
> =================================== I like the expressiveness of
> them, but I have two issues: 1. We do introduce some fingerprinting
> possibilities (20 questions) 2. I keep hearing that some OS's (that
> has a non negligible market share) just answer "yes, I can do that".
> Would it make sense to go with only optional constraints for the
> first version?
>
>
>
>>
>>
>
>
>
>

Received on Tuesday, 19 November 2013 14:14:34 UTC