Re: [sensors] Sensor discovery (#7)

I hope this is still active. Has there been any progress on a basic interface that a future sensor discovery API will take? I'd at least like to take it into account when designing some libraries I'm working on.

Adding to the work of @larsgk, I have two new use cases and some possible solutions.

## Use Case 6: Vendor-specific device subtypes

Real-world devices and sensors may not follow a simple `browser -> attached/virtual sensor -> unique type` flow. As an example: take the LEGO Bluetooth hubs. Each hub has ports that sensors/devices can be connected to, in addition to sensors integrated into the hub itself. A hub might have an accelerometer built in, and it might have a distance sensor plugged in on port A that exposes accelerometer and distance data. A vendor could have dozens of possible sensors with varying degrees of similar data.

## Use Case 7: Multiple sensor sources

Building on use case 6, there may be more than one source of sensors connected at a given time. Obviously web browsers will never standardize a LEGO Bluetooth hub API, but if the goal is a standardized discovery API, then it should be extensible to cover userspace-specific instances.

## Solution 1: Methods

This one was suggested above. Sensor discovery should be handled by a method that returns a async/non-async list of sensors:

```js
navigator.requestSensors(...)
```

A solution like this would be simple and familiar to users of other Web APIs. The biggest problem would be how to handle a huge range of possible devices and use cases.

## Solution 2: Events

Sensors could be globally announced using an event. The browser would handle built-in recognizable devices, while the user could dispatch the event manually for user-specific sensor types.

```js
navigator.requestSensorScan(...);
navigator.addEventListener("sensorfound", sensor => {})
```

This solves the problem of multiple sensors coming online at random times, which will likely be important for data-intensive long-running applications. A method like `requestSensorScan` could be used to set parameters that would help with battery-saving operations while also prompting the user for permission to scan for devices.

## Solution 3: Constructor parameters

This is easy enough. Just rely on additional parameters passed to the constructor of each sensor implementation.

```js
new CurrentSensor(...)
```

Nice and simple, but doesn't fit will with asynchrony. There's also the issue of security.

## Solution 4: Registry

With this solution, there would be a global registry of devices that could be populated by the browser and the user. Sensors could be a map similar to Web Components:

```js
navigator.sensors.get("accelerometer-named-james-by-scitech");
```

Alternately, if a field like `name` and/or `type` was standardized as part of the generic sensor API, sensors could be a WeakSet instead:

```js
for (const sensor of navigator.sensors) {
    if (sensor.name === "mydevice" && sensor.type === 1001) { ... }
}
```

Sensors would disappear from the registry once they are no longer available. This might also benefit from the recent work on custom registries for Web Components. On the other hand, it would almost certainly require events to announce that a new sensor is available.

-- 
GitHub Notification of comment by Symbitic
Please view or discuss this issue at https://github.com/w3c/sensors/issues/7#issuecomment-1830698718 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 28 November 2023 20:39:45 UTC