Re: [mediacapture-handle] Expose a MessagePort using Capture Handle (#70)

A few thoughts/suggestions:
- It should be required for capturer to know the captured origin to do postMessage. The fact capture handle is exposed at the track but not at controller level is something we should think of.
- We should try to reuse as much as possible existing web API patterns, at least this early in the design. The usual design is to expose postMessage()/onmessage and allow applications to transfer MessagePorts.
- I would try to make the proposal as small as possible, we can always extend it later. Some of the APIs you are describing might not be strictly required, for instance supportsMessagePort or started/stopped.

How about the following:
```
partial interface CaptureController {// Should it be named DisplayCaptureController?
    undefined postMessage(...);
    attribute EventHandler onmessage;
}

partial interface MediaDevices {
    // This event has a source attribute of type DisplayCapturer
    attribute EventHandler oncapturermessage; 
}

interface DisplayCapturer {
    undefined postMessage(...);
}

The assumption is that CaptureController would have access to the latest CaptureHandle information, which is not the case right now.
Another thing to consider is whether postMessage actually drops messages in case capture ends or capture changes of surface. We can probably add non-racy checks at postMessage call and event firing times, but I am unsure whether this is actually needed.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1406345920 using your GitHub account


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

Received on Friday, 27 January 2023 11:05:07 UTC