- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Oct 2024 20:57:22 +0000
- To: public-webrtc-logs@w3.org
> The specific change proposed in this issue is not about "short-term" scheduling. It is to make the API better. If a use case can be solved appropriately without introducing a dependency on another feature, then it is better to solve it without introducing that dependency. The fact that it results in an API that is easier to implement is a consequence of that design being better. I think this API is shortsighted. It's tightly coupled, artificially tied to main thread, and it reinvents postMessage. Our goal is to enable MediaStreamTrack processing in dedicated workers. This might include MediaStreamTracks originating in the worker someday, e.g. from an [OffscreenCanvas.captureStream()](https://github.com/w3c/mediacapture-fromelement/issues/65#issuecomment-1956065210) or other sources already exposed in the worker. Or an RTCDataChannel in a worker feeding a VideoTrackGenerator created there. Since [we all agree](https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2413866184) MediaStreamTracks will exist in workers eventually, the simplest API is the one that accepts them there. The idiomatic way to get data to workers is with postMessage, using [transferable objects](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects) if needed. So I disagree we shouldn't depend on other web platform features. It's doing it all ourselves that's the mistake. At least that's how I read [ยง 1.7 Add new capabilities with care](https://www.w3.org/TR/design-principles/#new-features). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2445316491 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 29 October 2024 20:57:23 UTC