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

Re: [sensors] Future proofing terminology

From: Mikhail Pozdnyakov via GitHub <sysbot+gh@w3.org>
Date: Fri, 29 Sep 2017 10:34:41 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-333092609-1506681268-sysbot+gh@w3.org>
> All that to say that the reporting frequency is a function of the sampling frequency and not the opposite.

Absolutely agree, and it is reflected in the [abstract operations](https://w3c.github.io/sensors/#abstract-operations). 

The problem as I see it now (and thanks for pointing it out!) is an unfortunate name and definition of the [Sensor.requestedReportingFrequency](https://w3c.github.io/sensors/#dom-sensor-requestedreportingfrequency-slot) internal slot. Now it might give a wrong impression that it is only to define [reporting frequency](https://w3c.github.io/sensors/#reporting-frequency) , actually this slot stores the `frequency` option and its value is used for these two things:
1) (indirectly) set the [requested sampling frequency](https://w3c.github.io/sensors/#requested-sampling-frequency) for the associated platform sensor.
2) set the [reporting frequency](https://w3c.github.io/sensors/#reporting-frequency)  for the given Sensor object (in practice it sets the upper limit because `reporting frequency` is always capped to `sampling frequency`).

I will rename the slot to `frequency` (so that it reflects the ctor option name) and provide a better description to avoid this confusion.

GitHub Notification of comment by pozdnyakov
Please view or discuss this issue at https://github.com/w3c/sensors/issues/294#issuecomment-333092609 using your GitHub account
Received on Friday, 29 September 2017 10:34:34 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:54 UTC