- From: Will Morgan via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Jul 2022 08:52:13 +0000
- To: public-device-apis-log@w3.org
Having the ALS work by relying on getUserMedia's side effects doesn't feel right to me, but maybe getUserMedia is actually a better API to use as developers can select the relevant sensor device. If this is for permission only, I'm tentatively OK with this, but I have some questions on how we might provide a more consistent API to developers. [Last year I looked into accessing the ALS via getUserMedia](https://github.com/w3c/ambient-light/issues/64#issuecomment-817129135), and concluded that it would require some spec changes to provide a consistent API surface. The main reasons were: - The existing ALS spec emits data on change rather than as a stream at regular intervals. - The UI and permission text for video tracks would need to change to encompass the ALS. That being said, the existing non-GUM spec doesn't let developers specify which sensor to use. For my use case, this would be useful as we need to specify the front facing camera. If the WebRTC WG (assuming this is the correct one?) would be interested in providing some guidance to reshape the API to make it more getUserMedia-y, that would be interesting. If it took this route, I'd be interested in knowing: * If we want a specialised MediaStreamTrack implementation from getUserMedia: * whether it provides a regular stream of data, or a stream that's only pushed to on quantized change events? * how a developer can specify that they want ambient light data, and not necessarily video? * If we didn't want to do this, is there a way to indicate a clear link between the ALS API and getUserMedia, given the edge cases that will exist around permission grant/revoke, adding/removing video devices, virtual cameras, and device selection? -- GitHub Notification of comment by willmorgan Please view or discuss this issue at https://github.com/w3c/ambient-light/issues/79#issuecomment-1175960515 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 July 2022 08:52:16 UTC