- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Mar 2023 14:01:51 +0000
- To: public-webrtc-logs@w3.org
> we want bidirectional messaging postMessage handles this with MessageEvent.source. We talked about this in past meetings, though it was never clearly described here. Let me know if it would help to write down more about this in this thread. > we can specify in the getter itself this new behavior. I am not clear about this. Either the getter is the place we check and then the MessagePort is live and will not be severed. Or the MessagePort might be severed if capture changes, which would be a change to how MessagePort works, so this will require changes/hooks to the MessagePort spec itself. Or it would With regards to behavior, I think we agree on 1, 2, 3, 6, 7, 8. About 4 and 5, it would be good to get use cases to motivate this. In any case, 1 to 8 are achievable with the postMessage approach. 6 is interesting in that the MessagePort approach would use the same object (MessagePort) for both transient channels and permanent channels. The postMessage approach would only use MessagePort for permanent channels. 9 is not about behavior but about ergonomics. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1479621441 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 14:01:53 UTC