- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Oct 2022 08:21:12 +0000
- To: public-webrtc-logs@w3.org
> If the capturer never responds, then the capturee never learns it's being captured. I object to many parts of the previous message, but I think we can zero in on one point first - the one I quoted. We fundamentally disagree on the alternative of MessagePort and what it would look like. I don't think the model you suggest is even possible, let alone desirable. First, feasibility. A tab can be captured by multiple capturers. A design centered around a MessagePort will require that the captured page register an event handler to receive a MessagePort after the capturer "dials in" by calling `CaptureController.getMessagePort()`. That means that captured pages cannot send any messages ahead of knowing if they're being captured. Second, even if your model were possible, it's evident that you noticed the following issue and tried to sidestep it - it's highly undesirable to require that captured pages routinely send the same message, which is why you introduced the caching mechanism. That is, you **reinvented the handle**. I now rest my case. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1283616859 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 October 2022 08:21:14 UTC