W3C home > Mailing lists > Public > public-device-apis-log@w3.org > October 2016

Re: [sensors] Default sensor configuration

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Wed, 26 Oct 2016 15:34:50 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-256384726-1477496088-sysbot+gh@w3.org>
> what is expected to be done if reporting mode declared in spec 
contradicts to the platform-provided one? 

So the only time this can be the case is if the spec requires periodic
 reporting mode and the platform doesn't support it. Afaik, the only 
cases were reporting mode is necessary is motion sensors, all of which
 are polled. So I don't really see scenarios where this really is an 
issue so far. But I might be missing some things.

> however it is not mentioned which sensor configuration is applied in
 this case (e.g. which frequency)

With regard to setting default frequency, the idea is that unless a 
specific frequency is requested by the developer, the UA can do what 
it wants. That _could_ be hard-coding a default, but it could also be 
modulating the frequency depending on different factors, such as 
battery life, security concerns, temperature of the device, user prefs
 or what not.

> Besides on platform level all the sensors anyway need the input 
frequency regardless of their polling mode, so it is not quite clear 
why constructor should raise exception if frequency is provided for 
'on change' sensor.

Afaik, that's not true of all sensors on all platforms (my 
understanding is sensor hubs don't behave that way), though it is a 
requirement for motion sensors. Unless there are use cases that 
require setting the frequency of sensors beyond motion sensors, there 
is little benefit in enabling this. It might also prevent UAs from 
building more performant or more battery efficient solutions.

When there is a use case for setting the frequency:

1. The sensor is said to have both a periodic and an undefined 
reporting mode.
1. If the developer request a given frequency, then,
    1. the sensor operates in periodic mode,
    1. it does a best effort to poll the HW at the requested frequency
1. otherwise, the sensor switches to undefined reporting mode, and the
 UA does what it wants (this can be to set a default freq, but it's 
encouraged to be one that is energy efficient).

When there is no use case for setting the frequency:

1. The sensor only has an undefined reporting mode.
1. If no frequency is defined by the developer, the sensor operates in
 undefined reporting mode, and the UA does what it wants (this can be 
to set a default frequency, but it's encouraged to be one that is 
energy efficient).
1. Otherwise, if the developer sets a frequency, and this is the 
contentious bit, we can decide to either:
    1. throw,
    2. silently fail,
    3. leave this implementation specific (some UA will use that 
frequency, some won't),
    
    we can't request all implementations to shift into periodic mode, 
however.

    Each of these three options has advantages and downsides. We 
should figure out what they are and pick accordingly.



-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/126#issuecomment-256384726 using
 your GitHub account
Received on Wednesday, 26 October 2016 15:34:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:52 UTC