- From: BlobTheKat via GitHub <sysbot+gh@w3.org>
- Date: Sat, 06 Jul 2024 00:29:59 +0000
- To: public-webrtc-logs@w3.org
I think a lot of the problem with more modern web APIs is that they are designed high level, and are uninteroperable with existing lower level APIs. Actually, the problem isn't that these APIs are high level, it's that they were designed quite narrow-mindedly with often a single use-case in mind, take for example - Service workers, designed exclusively for caching web pages offline (albeit privacy and security concerns fuel most of its prohibitive restrictions) - MediaStream, designed exclusively for WebRTC, mostly incapable of anything else - Web workers, missed potential for a very light and neat way to sandbox untrusted code - IndexedDB, with its restrictions on operation timing, don't prohibit but significantly increase the overhead of any usage pattern that wasn't intended. What all of these have in common is that they were only designed with at most a few use-cases in mind and therefore the specs often unintentionally completely prohibit any more creative use-cases, causing the need for new APIs later on, increasing to already-heavy browser engines For this specific issue, it will not get solved with a `getRawData`-like API but rather a fundamental change in perspective when it comes to designing specifications. As a shorter-term solution, `MediaRecorder` should standardise more formats, including raw-like formats like `wav` for audio and `mov` for audio-video. -- GitHub Notification of comment by BlobTheKat Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/327#issuecomment-2211538523 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 6 July 2024 00:30:01 UTC