- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Oct 2024 07:49:15 +0000
- To: public-webrtc-logs@w3.org
> 1. What do you think about this proposal? I think this proposal is ok. No need for a boolean flag in this case. I am not sure rvfc model (multiple callbacks, readd them when called) is necessary here. I would simplify the API to something like: ``` callback PostXXXCallback Promise<any> (); undefined setPostSurfaceSwitchingHandler(PostXXXCallback? callback); ``` > 2. If we instead pursue the `onconfigurationchange` approach, how do you envision that the application would know that a surface-switch has occurred and not some other change? We would expose `deviceId` through `getSettings`, `deviceId` being tied to a surface. Changing of `deviceId` means a surface switch. See the example in https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2432450287. My assessment is that both approaches solve the issue. I lean towards `autopause/onconfigurationchange` since it is smaller and seems good enough: - The callback API is bigger. And we might need to expose information to the callback that `getSettings` already exposes. - Whether we have a callback or not, `configurationchange` will fire in case of surface switch. - With the callback approach, we would need to decide whether `configurationchange` happens before this callback or not. It would somehow make sense to have `configurationchange` before so that `getSettings` contain useful information, but delaying the callback is not great, especially if we have clones in two contexts. - A track based approach is somehow more convenient for web developers: pausing happens per track's sinks, wherever the track is. For instance, one could let the preview track always unpause while having the sender's track being suspended until user clicks on some UI. - There are some advantages to a single decision place, it is somehow less error-prone if user forgets about one track that should be paused. - For exposing new tracks, I would guess a separate callback would be more convenient. Web app might not want auto pause but could be interested in new tracks. Also, audio or video tracks could be added outside of surface switching. - The promise based callback really shine if there is a need for asynchronicity, the need has not been demonstrated so far. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2437124841 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 25 October 2024 07:49:16 UTC