Re: Bug 23935 - Proposal: New syntax for constraints

On Wed, Dec 4, 2013 at 11:34 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> Today you're proposing "min", "max" and "mid" constraints. What about
> tomorrow? The specification shouldn't try to expose a declarative syntax for
> every kind of use-case possible. Just give applications access to the
> information they need and let *them* make the decision.

Well, given the getMediaDevices() function (why is that renamed in the
spec from getSources() or getSourceInfos() but not mentioned in the
ChangeLogs?), I assume we can always programmatically find out the min
and the max. This is a fairly new features. So, I agree that it may
not be necessary.

Regards,
Silvia.


> I am all for protecting users from information leakage when that information
> actually matters, but in this case it does not. This information is not
> confidential (like medical or bank records). We can already fingerprint
> browsers with high confidence: https://panopticlick.eff.org/
>
> Exposing a camera's capabilities is not going to make a difference with
> respect to fingerprinting. This battle is already long lost. All you'll
> achieve is a specification that is constantly chasing business use-cases
> (adding more properties with every passing day), and protecting users from a
> problem that doesn't actually exist.
>
> Business logic should remain in the application, not in the browser.
>
> Gili
>
>
> On 03/12/2013 5:23 PM, Silvia Pfeiffer wrote:
>
>
> On 4 Dec 2013 08:47, "Jan-Ivar Bruaroey" <jib@mozilla.com> wrote:
>>
>> On 12/3/13 3:53 PM, Jim Barnett wrote:
>>>
>>> Sorry, I wasn’t clear.  I was referring to the request for new values
>>> ‘max’, ‘min’ and ‘mid’, where {width: max} would mean “make it as wide as
>>> you can”.  “min” would ask for the minimum possible value, and ‘mid’ would
>>> mean “try for something in the middle of the range”.
>>
>>
>> As with anything in life, asking for the maximum without knowing what it
>> is strikes me as a very bad idea. Would you ask the Hulk to hit you as hard
>> as he can? Amount of Advil? Your app can already specify any number of
>> absolute values or ranges of values it knows about (and hopefully has been
>> tested with) Can you give me a use-case where this is not sufficient?
>
> You can only test with a limited amount of cameras. Specifying all possible
> resolutions just to get the best possible resolution from the actual camera
> that is attached to the computer will invariably lead to not getting the
> best possible resolution. I don't know of a way currently to tell my camera
> to give me it's highest or lowest resolution. Do you?
>
>> If expressiveness is a problem, we should address this directly, which is
>> what I believe my syntax proposal does. I can say:
>>
>> [ { width: 4096, height: 2160 },
>>   { width: 3840, height: 2160 },
>>   { width: 2880, height: 1800 },
>>   { width: { min: 1024, max: 4096 }, height: { min: 768, max: 2160 },
>> aspect: { min: 1.6, max: 1.9 } ]
>>
>> In this example, I prefer certain resolutions I have tested with (even
>> when higher ones are available), and only if I cannot get one of those exact
>> ones will I accept a range, but no less than 1024x768. How would you express
>> that today?
>
> I don't mind this new proposal. I am still keen to have special "max" and
> "min" values.
>
>> PS: In the above example, a clever UA could deduce that higher resolutions
>> are probably preferred in the range.
>
> I don't think UAs would be going to that extend of second-guessing the apo
> developers intention. There needs to be a simple way to tell it to give me
> highest or lowest resolution and frame rate.
>
> Cheers,
> Silvia.
>
>> PPS: Note how readable that was. I'll bet you intuitively understood what
>> that meant. Try that with mandatory/optional.
>>
>> .: Jan-Ivar :.
>>
>>
>>>   We haven’t  introduced these yet, but there seemed to be interest in
>>> them.  I think that the semantics would have to be that anything the UA
>>> chose counted as correct.  Just because the property ‘foo’ defines its range
>>> to be 0-1000 doesn’t mean that  the UA can actually set a value of 1000 in
>>> every case (particularly if there are other interacting properties), so
>>> whatever the UA gives you has to count as “as good as I could do”.
>>>
>>>
>>>
>>> -          Jim
>>>
>>>
>>>
>>> From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
>>> Sent: Tuesday, December 03, 2013 3:47 PM
>>> To: Jim Barnett; public-media-capture@w3.org
>>> Subject: Re: Bug 23935 - Proposal: New syntax for constraints
>>>
>>>
>>>
>>> On 11/27/13 10:55 AM, Jim Barnett wrote:
>>>>
>>>> I prefer the current syntax.  It is more compact and makes back-off
>>>> easier.  Furthermore, it makes the semantics of ‘best effort’ values like
>>>> min/max/mid easy to understand, at least in the case of optional
>>>> constraints.  Suppose we have optional constraints  “prop1 max, prop2 max,
>>>> prop3 max”.  This would  mean:  set prop1 to the largest value you can, the
>>>> set prop2 to the largest value you can without changing prop1, then set
>>>> prop3 to the largest value you can get without changing  prop1 or prop2.
>>>> The ordering of the constraints specifies the ordering of the optimizations.
>>>
>>>
>>> I don't understand your use of min and max (what is mid?) - Can you
>>> please use actual syntax?
>>>
>>> Are you saying that { width: { max: 2880 } } must return the highest
>>> value possible, up to and including 2880? If so, that doesn't match my
>>> understanding. Where in the spec do you read that?
>>>
>>> My interpretation is that there is no such guarantee, and that, given no
>>> lower bound, browsers can return anything from the lowest possible value and
>>> up to and including 2880.
>>>
>>> .: Jan-Ivar :.
>>
>>
>
>

Received on Wednesday, 4 December 2013 06:54:21 UTC