- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 May 2022 19:14:34 +0000
- To: public-webrtc-logs@w3.org
> I would only design a synchronous interface if it was obvious that any reasonable implementation would never have a need for a step involving interactions with entities outside the renderer process hosting the API. I do not think creating a cropTarget requires any "interactions with entities outside the renderer process", depending of course of your definition of interactions. Contrary to actually cropping a track for instance. Hence my conclusion that creating a CropTarget does not need to be asynchronous while cropTo should be asynchronous. > How can an algorithm that posts a task to a different task queue be considered synchronous? Sorry, this was misleading. What I tried to say is that the call to postMessage happens synchronously with the creation of the object. The whole postMessage algorithm is of course asynchronous. @eladalon1983 mentioned several times that it has to be asynchronous between the time the web app wants to create the object and the time the web app wants to transfer the object. Performances and potential race conditions were mentioned. The point I am making is that this issue has been solved multiple times and for objects more complex than a CropTarget. This makes me think asynchronicity is not needed by reasonable UA implementations, they will just leverage existing UA patterns. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1128040467 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 16 May 2022 19:14:35 UTC