- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Nov 2023 18:58:46 +0000
- To: public-webrtc-logs@w3.org
> A user agent can trivially limit source-switching (and its implementation burden) to the non-injection kind by limiting the feature to apps that have called setSourceSwitchCallback ahead of time. Typically, when we think user agents must not do something, we specify that they `MUST NOT` do it. I cannot think of a precedent where we chose a more complex API shape in order to tie the UA to the mast, so to speak. Can you? > Conversely, apps have more freedom with controller.onsourceswitch in that they can get notified about switching (including injection) ahead of time without pre-committing to a decision. This flexibility is not free. * It adds a side-effect to the `onsourceswitch` setter, which is an anti-pattern. * It requires more code from the app - even if the app doesn't want to use this feature. (Foreshadowing.) * It might be error-prone for the app, which might fail to call `preventDefault()` on some branches. * It's more complicated to spec. * It's more complicated to implement. What benefits offset these costs? Can you give a concrete example of an application that *needs* to make the decision to source-inject or not on a dynamic basis? -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/255#issuecomment-1808822394 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 13 November 2023 18:58:48 UTC