- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Oct 2024 22:39:09 +0000
- To: public-webrtc-logs@w3.org
I thought the plan was to summarize our positions in a separate issue and ask TAG for their opinion, but here's my reply. > > 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, > This API is not tighly coupled with anything. If a developer wants to transfer a track to a Worker and manage all its state and lifetime there, there is nothing in the proposed API preventing it. Just like nothing prevents developers from managing the track on Window if that is what they prefer. The one that forces developers to use track transferability even if they'd rather not use it is the one that tightly couples two features that should be independent of each other. > > and it reinvents postMessage. > This API does not reinvent postMessage anymore than encoded transform does. If this is such a bad thing, should I file an issue in encoded transform to eliminate the same pattern there and require that RTCRtpSender and RTCRtpReceiver (or some other object) be transferrable too? > 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. All this can be supported without tightly coupling mediacapture-transform with track transferability. I don't think it is possible to find a single use case where forcing the user to use track transferability is better than allowing it, but without forcing it. > > 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. > No it's not the simplest API. It is a lot more complex to tightly couple two features that should be independent. It is not only more complex for UA implementors, which cannot develop the features independently; but, more importantly, it is more complex for Web developers, who are forced to use an unnecessary feature and complex workarounds to solve otherwise nonexisting problems. Now Web developers are forced to clone a track, transfer one of them, and introduce track management logic in two separate realms even if their preference would be to do all track management on Window. Even more importantly, the proposed API does not even need to be a replacement for the existing one. Since this API removes the tight coupling between both features, it isn't really much of a problem to provide the constructors in the existing API as a convenience for hypothetical applications that would prefer to do all track management in the worker. > 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. > Again I ask, why is this a problem. Is encoded transform non-idiomatic? Should we eliminate the RTCRtpScriptTransform constructor and introduce a new transferable object there to be used with postMessage, or make senders and receivers transferable? Or is it a problem here, but not there? > So I disagree we shouldn't depend on other web platform features. It's doing it all ourselves that's the mistake. The mistake is to force a dependency on another feature that should be independent. I'd like to see a single use case where this dependency provides a benefit for web developers compared to having the features be orthogonal. > At least that's how I read [ยง 1.7 Add new capabilities with care](https://www.w3.org/TR/design-principles/#new-features). We read it very differently. Adding dependencies between features that should be orthogonal and forcing developers to use complex workarounds to deal with those unnecessary dependencies is,, in my view, the opposite of adding capabilities with care. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2445454842 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 22:39:10 UTC