W3C home > Mailing lists > Public > public-device-apis-log@w3.org > October 2016

[sensors] Multiple sensor & sensor change discoverability

From: rektide via GitHub <sysbot+gh@w3.org>
Date: Mon, 10 Oct 2016 18:22:18 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-182081152-1476123736-sysbot+gh@w3.org>
rektide has just created a new issue for 
https://github.com/w3c/sensors:

== Multiple sensor & sensor change discoverability ==
Hi.

In [Background](https://w3c.github.io/sensors/#background), we see 
some discussion of how multiple sensors are to be dealt with. I'm 
generally pretty ok with using SensorOptions passed to a sensor 
constructor to pick non-default sensors. There ought however be:
1. Some way to discover these sensors (such that my code can adapt to 
an 18 wheeler's worth of DirectTirePressureSensors automatically).
2. A way to detect sensors joining & leaving (for example, a gamepad 
with gyro being connected).

Some existing examples of specs tackling discoverability:
* **[Gamepad 
API](https://w3c.github.io/gamepad/#navigator-interface-extension)** 
enumerates gamepads with `getGamepads()` and exposes 
`gamepadconnected` and `gamepaddisconnected` events.
* **[Media Capture and 
Streams](https://www.w3.org/TR/mediacapture-streams/#enumerating-devices)**
 has an `enumerateDevices()` that returns a promise of all devices, 
and exposes a `devicechange` event signalling any change, with no 
payload.

There's good material here that could be replicated. Overall I'd 
prefer connected/disconnected events, since the sensor list could grow
 to be a very very considerable size and manually diffing that list to
 identify differences could be unpleasant.

Thank you all.

Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/141 using your GitHub account
Received on Monday, 10 October 2016 18:22:25 UTC

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