Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple sensor & sensor change discoverability #141

Closed
rektide opened this issue Oct 10, 2016 · 1 comment
Closed

Multiple sensor & sensor change discoverability #141

rektide opened this issue Oct 10, 2016 · 1 comment

Comments

@rektide
Copy link

rektide commented Oct 10, 2016

Hi.

In 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 enumerates gamepads with getGamepads() and exposes gamepadconnected and gamepaddisconnected events.
  • Media Capture and Streams 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.

@rektide
Copy link
Author

rektide commented Oct 10, 2016

Closing as duplicate of #7.

@rektide rektide closed this as completed Oct 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant