Re: [mediacapture-main] Should devicechange fire when the device info changes? (#966)

> I'm asking about the use case, the real-world problem that requires this change that isn't possible today.

I've already mentioned it. Update the UI to reflect available devices, notify the user, know when/if to call getUserMedia again.  Is your position that those are use cases we should not support via devicechange? We support them anyway via calling enumerateDevices() in a loop.


> [Earlier](https://github.com/w3c/mediacapture-main/issues/966#issuecomment-1726616311) I clarified two reasons why the observable set may change:
> 
> 1. a "real" device change (use case: app wants to react to a user having just inserted a new physical device)
> 2. getUserMedia ungates full device info of more than one of a kind of device to choose from
> 
> I trust it's clear that if the same event fires for both 1 and 2 then that interferes with detecting 1. The problem [use case](https://github.com/w3c/mediacapture-main/issues/966#issuecomment-1727807059) I gave was getUserMedia racing with the user putting on their headset.
> 

Why? The preferred pattern is to use [plan events](https://www.w3.org/TR/design-principles/#state-and-subclassing), like `devicechange` and then let the application examine the updated state to determine what happened and/or what needs to be done to properly react to the event.
Do you also not support firing the event when the default device changes?  Does that not interfere with detecting addition/removal?

> Number 2 is the norm frankly. Most devices (cellphones) have more than one device of a kind. In the spec, apps should assume they don't have the full set of information ahead of gUM (like in Safari), and not need an event to tell them this.
> 
> > if/when to make a new getUserMedia call
> 
> Asking for getUserMedia twice is an anti-pattern. This is why we have constraints — and why Firefox has a picker — to help pick the correct device up front. Per-device permission models work poorly otherwise. I'm not going to call out specific VC apps, but you know who you are.
> 

What is wrong about calling gUM more than once? And what is wrong about updating a UI that lists available devices based on a change in the result of enumerateDevices()?


> > or to provide a notification to the user (e.g., to request permission again).
> 
> Using enumerateDevices to detect permission is also an antipattern. Hopefully this clarifies why I'm opposed to this change.

enumerateDevices() would be used to examine the updated state, just like with any other plain event. Not specifically to check permissions.
Let's say the user does something that makes a device unavailable (other than physically removing it). What is wrong about the application informing the user that it can't capture anymore, and waiting for the device to become available to call gUM() again?


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/966#issuecomment-1734077114 using your GitHub account


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

Received on Monday, 25 September 2023 16:20:41 UTC