Re: [webrtc-encoded-transform] Generalize ScriptTransform constructor to allow main-thread processing (#89)

> If I understand correctly, forwarding the stream from the Worker to some other MessagePort (where ever that ends up) is allowed, so where is the benefit of making it harder for developers to do just that?

Things already being possible in JS generally counts _against_ exposing new APIs, not for it.

Also, just because something is possible doesn't make it desirable or without cost. Transferable streams produce a _"[readable side in another realm](https://streams.spec.whatwg.org/#transferrable-streams)"_ where the original realm feeding that readable in this case is the dedicated worker provided in the constructor.

> There are complex Worker scenarios that would benefit from not receiving the stream at a Worker-global entrypoint.

What benefit? It seems hard to do anything in a worker without a Worker-global entrypoint e.g. `self.onmessage`.

> I can understand that you want to incentivise the use of Workers in this API (although I'm torn on the chosen method) but I believe allowing for `MessagePort` in the constructor could be a sweet spot and would also allow main thread processing in a "clunky but not so clunky" way.

The `MessagePort` idea was [abandoned up-thread](https://github.com/w3c/webrtc-encoded-transform/issues/89#issuecomment-1833265791) so I won't rehash the arguments against it.

But a goal of the API is to avoid implicit main-thread, which _requires_ a `worker` argument, and a `MessagePort` (another tunneling concept) is no substitute. https://github.com/whatwg/streams/issues/1124 is selling this idea that it doesn't matter where readables are initially exposed, which is how we got into this mess, but it does, unless we want to have to rely on UA optimizations that break semantics.


-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/89#issuecomment-2004497929 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 18 March 2024 17:15:36 UTC