W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2013

Re: gUM's optional constraints algorithm penalizes user-choice chasing best-match for webpage

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 02 Sep 2013 11:39:55 +0200
Message-ID: <52245CEB.6040306@alvestrand.no>
To: public-webrtc@w3.org
On 09/02/2013 07:55 AM, Dominique Hazael-Massieux wrote:
> Le samedi 31 août 2013 à 10:26 -0700, Martin Thomson a écrit :
>> On 31 August 2013 00:43, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>>> The reason this works is that our (unchanged) core "remove-from-list"
>>> algorithm ignores zero-reducing optional constraints, which makes it more
>>> lenient the smaller the starting set is.
>> I'd go even further and not remove anything that is marked with an
>> optional constraint.  I'd use optional constraints to select a
>> default, and maybe to order sources.
> That also sounds good to me as well; in particular, it reduces the
> unbalance of optional constraints as a all or nothing approach (either
> all the optional constraints are satisfied, or none will be particularly
> sought to be satisfied).
Dom, I can't parse that sentence in the context of the current algorithm.

1) The use of the word "unbalance" seems to indicate that there are two 
things that could concievably be kept in balance. I can't tell what the 
two things are.

2) I can't parse how the optional constraints mechanism (a sequence that 
is used to iteratively reduce the candidate configuration set, stopping 
when applying the next constraint would reduce the candidate 
configuration set to zero) fits with the description of "a all or 
nothing approach".

So obviously I am not parsing your language properly. Could you please 
help me?


>
> This would mean changing the constraint algorithm so that the
> secondPassSet doesn't replace candidateSet, but instead is used by the
> UA to help the user select an appropriate device (the details of which
> would be left up to the UA).
>
> Dom
>
>
>
Received on Monday, 2 September 2013 09:40:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC