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

[sensors] Define processing model

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Fri, 19 May 2017 07:36:34 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-229894376-1495179392-sysbot+gh@w3.org>
tobie has just created a new issue for https://github.com/w3c/sensors:

== Define processing model ==
Some of our earliest issues involved tying sensor polling to animation frames (see #4).

Initial implementor feedback pushed in the same direction, for performance reasons, see: https://github.com/w3c/sensors/issues/152#issuecomment-267967852.

So we designed a system around an animation frame funnel, where polling frequencies > animation frame rate were possible, but new readings wouldn't be delivered until the new animation frame request. This implied creating an API to handle buffered readings (see #171).

Now the latest feedback from implementors seems to at least partially reconsider this, see the thread at https://bugs.chromium.org/p/chromium/issues/detail?id=715872.

Reducing latency, gathering data a high frequencies, etc., are important requirements for sensors. The WG needs to understand better how these implementation design choices influence these requirements, and then needs to design a processing model that is usable by developers, delivers on these requirements, permits interoperability and allows vendors to implement sensors in a performant way.

As a first step, it might be useful to resurface the use case document, improve it (a lot) and move use cases and requirements to the spec.

Please view or discuss this issue at https://github.com/w3c/sensors/issues/198 using your GitHub account
Received on Friday, 19 May 2017 07:36:40 UTC

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