- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Oct 2024 13:51:17 +0000
- To: public-webrtc-logs@w3.org
> And I do not really see a case for multiple event listeners for this switch case A singular callback assumes a single downstream consumer. An app may have multiple consumers of an active screen-capture, e.g. a transmitter, a preview, and a recorder, each with distinct downstream needs. Tracks can be cloned, but a CaptureController cannot. So this becomes a choke point. We don't want different parts of an app competing to set the same callback and overwrite each other. The web platform tries hard to avoid single-consumer APIs. See [§ 7.3. Don’t invent your own event listener-like infrastructure](https://w3ctag.github.io/design-principles/#dont-invent-event-like), and [requestVideoFrameCallback](https://wicg.github.io/video-rvfc/#dom-htmlvideoelement-requestvideoframecallback). I think we need a good reason to deviate from these principles. > (web devs already have configuration change anyway). Those are per-track and cannot tell you whether the source changed or e.g. was just resized. > And the spec can be made clear that MediaStreamTracks are not created if the callback is not set. This is more difficult with events. This seems like a marginal optimization compared to a such a significant user action. > This is sort of similar to MediaSession going with callbacks as action handlers. That's a fairly recent API with its own [flaws](https://github.com/w3c/mediasession/issues/228#issuecomment-887788017). But it has a good reason: Many of its actions rely on the website to maintain a singular state. What's our reason? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/4#issuecomment-2391481523 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 October 2024 13:51:19 UTC