- 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
> 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