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

Re: [sensors] Default sensor configuration

From: Mikhail Pozdnyakov via GitHub <sysbot+gh@w3.org>
Date: Thu, 27 Oct 2016 11:27:51 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-256615869-1477567669-sysbot+gh@w3.org>
> 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.

Our team has implemented Generic Sensor API based sensors 
(AmbientLight, Accelerometer, Gyroscope and Magnetometer) in Chromium 
for all the supported platforms (Android, Windows, Chrome OS/Linux, 
Mac).

We can confirm that platform sensor APIs on Android, Windows, Chrome 
OS/Linux (IIO) accept polling frequency as an input parameter for any 
sensor type, whatever reporting mode it provides. Therefore reporting 
mode is just an implementation detail that allows to optimize sensor 
reading update strategy. 

Can we do the following:
1) Omit the "reporting mode" term completely from the specification 
(as it is an implementation detail)
2) Allow user to pass frequency hint as an optional parameter for any 
sensor and let UA decide how to handle it.


-- 
GitHub Notification of comment by pozdnyakov
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/126#issuecomment-256615869 using
 your GitHub account
Received on Thursday, 27 October 2016 11:28:01 UTC

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