- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Oct 2016 13:08:18 +0000
- To: public-device-apis-log@w3.org
> Reporting mode can be different for same sensor type, even on the same platform. Note that the reporting mode distinctions the spec makes are not the same as the ones the Android platform makes. The spec has the following: - periodic: requires a frequency, - non-periodic: which is basically whatever the implementor wants to do (can be periodic, can be on change, whatever). Periodic reporting mode is required for doing anything useful with low-level motion sensors. It is not for the rest of sensors. I'd like to hear more details about the motion sensors which don't provide continuous data on Windows, so we can decide what to do with those. The main question being to see whether or not such sensors would actually enable the use cases we care about. > Frequency is always used except for special sensors e.g. trigger. As mentioned [above](https://github.com/w3c/sensors/issues/126#issuecomment-256632571), what you're passing Android `On Change` sensors isn't polling frequency. We should not conflate these two things. In the case where setting frequency is needed (for dumb sensor that are polled) but is not a developer requirement (afaik, everything but motion sensors), the polling frequency is best left implementation specific. In a subsequent version of the spec, we can add further hints to help the UA pick a better polling strategy, but that's not a requirement for level 1. **There are no requirements for setting the frequency of non motion sensors for now.** Furthermore, there are explicit warnings against doing so from other stakeholders (e.g. @gmandyam). -- GitHub Notification of comment by tobie Please view or discuss this issue at https://github.com/w3c/sensors/issues/126#issuecomment-256915708 using your GitHub account
Received on Friday, 28 October 2016 13:08:24 UTC