- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Mar 2017 14:01:17 +0000
- To: public-device-apis-log@w3.org
> We could also make it an argument to a generic orientation sensor,
like say { type: "compass" | "device" | "gamepad" | "vr-headset" ... }
What's interesting is that the above four have massively different
latency, accuracy and energy consumption characteristics and don't
rely on the same underlying HW sensors.
The question is how should we expose that to the API consumer?
Basically, how do we strike the right balance between providing the
right underlying primitives and making it easy for developers to use
the APIs.
In the spirit of the extensible web manifesto, we'd lay bare the
underlying structures on which these sensors are based, leaving it to
JS libraries to offer more user-friendly domain-specific APIs. And
then only pave the cowpath.
--
GitHub Notification of comment by tobie
Please view or discuss this issue at
https://github.com/w3c/sensors/issues/170#issuecomment-283960197 using
your GitHub account
Received on Friday, 3 March 2017 14:01:34 UTC