Re: [mediacapture-region] What makes CropTarget special to require an asynchronous creation? (#17)

I want to settle this discussion about Promises. And I don't want to leave your message unanswered. Let's **briefly** examine the [three other APIs](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1064903263) you've brought up:
* **MessageChannel:**
  * If implementing with direct communication between the processes, the risk involved is a necessary evil. This cannot be said for CropTarget. Discoverability in either direction is not a requirement here, and confers little to no benefit.
  * If implementing with mediation via another process, the story gets more complicated. A valid implementation can hide that it's asynchronically minting identifiers, behind the moment of posting the MessageChannel to the other document. (Some compromises are required, though.) But I don't want to discuss this because it would lose track of the topic - see below.
* **MediaStreamTrack:**
  * These are **not** currently transferrable in Chrome - not synchronously, not at all. To claim it's possible one needs to present an implementation  as proof, not a specification. (Does it work on Safari or Firefox yet? [This demo](https://cheerful-zany-editorial.glitch.me/) suggests that it's not, as of 2022-03-31.)
  * My colleauges working on mst-transferability tell me that they are running into **a lot** of issues **precisely** because of the requirement that they be "synchronously transferable".
* **RTCDataChannel:**
  * As of the time of this writing, these don't appear to be transferable in neither [the specification](https://w3c.github.io/webrtc-pc/#webidl-1143016005) nor [Chrome's implementation](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_data_channel.idl).

I hope we can proceed without trifurcating the discussion. I did not want to leave your points unanswered, but **deep-diving into these three examples will be unwise**. We have an independent engineering question here, and it can be resolved on its own merits. These precedents do not seem applicable. Nor should we assume that mistakes and compromises were not made in the design of these other APIs. Let's discuss our own case on its own merits.

I believe I've made a compelling case for why `produceCropTarget()` **should** be asynchronous.
* It allows CropTarget to avoid potentially-risk identifiers.
* It's the conservative design choice to make.
* It imposes negligible costs on all constituencies.
* There's nothing stopping implementations from returning a pre-resolved Promise if they so wish.

Let's go with an asynchronous produceCropTarget().


-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1085056027 using your GitHub account


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

Received on Thursday, 31 March 2022 20:13:21 UTC