- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Sep 2023 13:46:12 +0000
- To: public-webrtc-logs@w3.org
> I'd like for someone to show how an app can do that and cover all the edge-cases we've discussed so far (racing with gUM's device exposure gate, racing with enumerateDevices itself, relying on pre-gUM vs post-gUM baseline, handling pre-gUM insertion (from 0→1 devices). Races are still possible even if you restrict the event to insertion/removal. Sometimes they can be outside the UA (e.g., at the OS level, different processes can have different views of the set of devices). We can mitigate them with mechanisms like @youennf's proposal to delay firing a `devicechange` event while API calls are outstanding, but probably not eliminate them entirely. > The more I think about all the edge-cases I'm not confident apps will be able to decode device insertion correctly in all cases. Do we need a discrete deviceinserted event? I'm open to having another event type, but I don't think that will completely solve the generic problem of races. Also, I don't think these races are a major problem in practice for VC applications, since they are very rare and the consequences aren't particularly terrible. Being able to present the correct choices in a UI when the set of available devices changes (no races) looks like a more important concern IMO. I believe in most cases the application is more interested in knowing the latest state of devices than the causes that led to that state. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/966#issuecomment-1735576764 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 26 September 2023 13:46:14 UTC