- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Jun 2022 21:31:07 +0000
- To: public-webrtc-logs@w3.org
> The W3C design principles cite interprocess communications (IPC) as a potential reason to choose async over sync, so they don't provide much in the way of definitive guidance here. It says to use sync if the "[API ... will not be _blocked_ by ... inter-process communication.](https://www.w3.org/TR/design-principles/#synchronous)" (emphasis on _blocked_) I hope I [showed](https://docs.google.com/presentation/d/1-SgzfMAeVG3u5vErJncC7OKDTGNDzSOMg_78LP8SULk/edit#slide=id.g133845ed595_0_2) that any IPC in `fromElement` is (premature) optimization, and that there's no reason for JS to block on it since it cannot fail, and doing so just [slows things down](https://docs.google.com/presentation/d/1-SgzfMAeVG3u5vErJncC7OKDTGNDzSOMg_78LP8SULk/edit#slide=id.g131149eddb2_0_24). Needs for failure are discussed and disputed in #48. > whereas some implementers claim they cannot live with the sync approach. We talked about this on the call, and my recollection was this argument reduced to convenience of implementation, i.e. _not_ a need. > For example, resource allocation could be moved from `CropTarget()` to `cropTo()`, since the latter is async. Exactly. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1167925739 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 27 June 2022 21:31:09 UTC