- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 May 2021 00:59:13 +0000
- To: public-webrtc-logs@w3.org
> I'm saying that going against the established pattern of exposing in both places requires a stronger argument than "the user might do something wrong in certain circumstances" which is the only argument given so far. I'm hearing no reason other than pattern, and I suspect those patterns are largely historical. I.e. workers are still a relatively young concept compared to the size of the platform, so that might explain why many APIs were exposed to main thread first. WebIDL lets us specify exposure discretely, and I see no established *rationale* to back up why exposure must follow any pattern. If you have one, please point me to it, otherwise I see no reason to follow a pattern not backed by rationale. Also, AudioWorklet is a clear example that breaks that pattern: we had main thread exposure, and removed it on purpose for good reasons, which I [gave](https://github.com/w3c/mediacapture-transform/issues/23#issuecomment-836812770). That this ended up being a worklet rather than a worker, I don't think had anything to do with any rule that APIs cannot be exposed in workers only. I've also seen no proposals to transfer `ScriptProcessorNode`. I also disagree that being conservative requires arguments. I think being cautious with these low-level APIs is the right approach, which means requiring arguments to be anything but conservative. It'll be hard to put the genie back in the bottle. > An advantage worklets can provide is the ability to run on any thread, including real-time threads, but that is not needed for our intended use cases. What use case is that? "[Funny hats](https://w3c.github.io/mediacapture-transform/#introduction)" and "Virtual Reality Gaming" both seem real-time to me. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/23#issuecomment-842743240 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 May 2021 00:59:30 UTC