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

Thanks Harald for moving this to the right list.

On 9/1/13 1:06 AM, Martin Thomson wrote:
> On 31 August 2013 12:12, Jan-Ivar Bruaroey<jib@mozilla.com>  wrote:
>> We could make further changes but I worry it wont generalize to all
>> constraints the way this relatively minor change does.
> Your proposal is somewhat less efficient, if that's the concern.  I
> was thinking that each "miss" would bump the source down a category,
> so that you get all the sources that meet all criteria, then the
> sources that meet all bar one criterion, then the sources that meet
> all bar two, and so forth.
>
> Simple to implement, no two-pass processing, not a big change.  Thoughts?

I would leave it to browsers to pick efficient algorithms, and would 
prefer the spec to concern itself with explaining the API (which appears 
to be a language in this case). If the only way to explain the API is by 
way of implementation-example, I would prefer a comprehensible example 
over an efficient one.

The core algorithm seems fine to me: It reduces a set of /otherwise 
//available/ candidates based on constraints set by the webpage. The 
constraint-inputs act in this regard as a proxy for the webpage in the 
negotiation with the user over which source to use (like an eBay 
auto-bidder). The negotiation itself takes place inside the browser.

I think we should feel satisfied that the spec defines this proxy, and 
that we should step back from dictating how the negotiation itself must 
take place. Specifically:

 1. Don't dictate that the starting point must always be ALL sources,
 2. Don't dictate how often the proxy (algorithm) can be run, or on what,
 3. Don't dictate to the browser when it is allowed to consult with its
    user.


Because, frankly, it seems out of scope to do so.


For example, consider a hypothetical paranoid browser that let users 
narrow the list of cameras to offer the webpage /before/ considering the 
webpage's needs. By user-limiting on the input-end, it should be obvious 
that the user has control that limits the webpage, not the other way 
around. You could argue that this would be a terrible user experience 
(and I would agree), but my point is that this is a decision for the 
paranoid browser to make, not the spec.


In practice, with the above interpretation, I am confident that browsers 
will make nice user-experiences here that respects the wishes of the 
webpage without compromising choice for the user.


.: Jan-Ivar :.