- From: rektide via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Oct 2016 18:22:18 +0000
- To: public-device-apis-log@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