W3C home > Mailing lists > Public > public-device-apis-log@w3.org > May 2017

Re: [sensors] Call 'onchange' on a Senor instance considering its own frequency hint

From: Mikhail Pozdnyakov via GitHub <sysbot+gh@w3.org>
Date: Mon, 29 May 2017 09:49:54 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-304621313-1496051393-sysbot+gh@w3.org>
> What do you mean by behavior, here? Getting the value of attributes returning a fresher value or something else?

yeah, that `slowSensor.x` could be updated at different frequencies at arbitrary periods of time depending on other `Sensor` instances activation.

Reading through #8, I found that the rational for returning the same values from all Sensor objects is
https://github.com/w3c/sensors/issues/8#issuecomment-63327311 : "In that way you will always be working with the freshest sensor data." - which makes sense from the user perspective (why would you need outdated data?)

**Generic thoughts:**

We do not have good options till we have multiple Sensor instances bound to the same platform sensor:

**Option 1** (the current ED):
All Sensor objects point to the same data and 'onchange' is fired simultaneously, ignoring individual frequency hint

Problems: basically described in this issue
- objects are not decoupled from each other
- frequency at which `sensor.x` is updated and at which `change` is fired may vary arbitrary, apart from the given hint.

**Option 2** (https://github.com/w3c/sensors/issues/8#issuecomment-63327311):

All Sensor objects point to the same data but the `change` event fires at different intervals on the different objects as specified in their respective initialization options.

Problems:
- objects are still not decoupled from each other
- frequency at which `sensor.x` is updated still may vary arbitrary
- `onchange` notification is not synced with returned data update


**Option 3** (https://github.com/w3c/sensors/pull/210)
Sensor objects have their own reading copies

- Slower Sensors objects can have "outdated" reading

(In the above list I did not mention implementation complexity and memory&cpu resources required: it is increasing steadily from option 1 to option 3)

The only good option would be having 1-to-1 mapping between Sensor object and platform sensor.

Even though #8 and #9 are closed I propose to file a new dedicated issue and start working on it.
Meanwhile Chromium implementation can follow the **option 1** which is currently in ED and easier to implement, hopefully not many users will create multiple Sensor instances of the same type :-/

-- 
GitHub Notification of comment by pozdnyakov
Please view or discuss this issue at https://github.com/w3c/sensors/issues/152#issuecomment-304621313 using your GitHub account
Received on Monday, 29 May 2017 09:50:00 UTC

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