- From: Yoav Weiss via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2022 08:59:03 +0000
- To: public-webrtc-logs@w3.org
Apologies for the delay in responding here. To reduce confusion (mine or otherwise), let me try to summarize my current understanding. Based on @eladalon1983’s [previous comment](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1027843349) here, minting *[can fail](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/media/capture/crop_id_web_contents_helper.h;l=38;drc=f10df0040d17b75ac96491b1c009550e97778bc9)*. Such failures can happen if minting is done in the browser process or in the renderer process itself, e.g. if the developer is minting too many such tokens, and the implementation wants to impose limits on that. It seems reasonable that the API shape would allow for such failures to happen at minting time, and not just at crop time (where they’d be caught by a separate document, on a potentially separate origin). Given the above, it seems to me that choosing a sync API shape for minting would significantly restrict implementations in their flexibility and force them to implement renderer-to-renderer communication channels which would require extra care for security purposes, and may suffer from performance issues, as pointed out [up-thread](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1128595737). Those potential performance issues would then cause *user* friction and frustration: We either introduce a delay when minting the tokens synchronously (as there’s a lock on the minting container, for off-thread IPC handling), or we introduce a delay when cropping (in case we need to establish communications with the other renderer’s busy main thread). Reading through the [use sync when appropriate](https://w3ctag.github.io/design-principles/#synchronous) Web Platform Design Principle, it calls out the use of locks and IPCs as ones that *require async designs*. I think we all agree that a performant implementation of renderer-to-renderer communications would require a lock, at the very least. Compounding the above with the [TAG’s opinion](https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/04-25-minutes.md#media-capture-region) that an async design here doesn’t significantly decrease developer ergonomics, and the fact that this issue hasn’t come up as a hurdle to adoption as part of the [Origin Trial in Chrome](https://developer.chrome.com/origintrials/#/view_trial/2257429313219461121), I’m unconvinced that moving the API to be sync is warranted, as far as the priority of constituencies is concerned. Starting out with an async API also seems more conservative, and a decision we could revert at a later point, if we deem it necessary. Implementations that don’t believe the above issues warrant asynchronicity could always return an immediately resolved Promise. -- GitHub Notification of comment by yoavweiss Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1129753450 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 May 2022 08:59:05 UTC