- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Mar 2023 12:25:23 +0000
- To: public-webrtc-logs@w3.org
> I think that it's a feature that `getMessagePort()` gives you a port that will auto-cancel itself when the capture stops. postMessage can allow this naturally, if we decide so. Note also that, to implement this rule in MessagePort, we would need to create a new special Message flavour, which does not seem great. I haven't made my mind on whether we should enforce this rule or not, it would be worth digging into this (feedback provided earlier in this thread https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1415366828). > It means the captured application can trust that it's only sending back messages to an entity that's still capturing it. MessagePorts are transferable so there is no guarantee that the message will be processed by the capturing application. MessagePort and capturing application may also live in different processes/different threads leading to unavoidable race conditions. The postMessage approach gives us more flexility here. If we want to, we can decide to enforce this rule without any race conditions. > I'm going to jot down a list of the benefits and drawbacks of the two approaches Before diving into API shape, it would be good to nail down the exact behavior we want. Pros and cons are always good though, let's continue this discussion in a more structured way. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1479484117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 March 2023 12:25:24 UTC