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

> > we want bidirectional messaging
>
> postMessage handles this with MessageEvent.source.

Both are solutions provide bidirectional messaging, so we seem to agree on this being a requirement. Great!

> > we can specify in the getter itself this new behavior.
> 
> \[...\] so this will require changes/hooks to the MessagePort spec itself. Or it would

Please note that you have an unterminated thought there. I'd love to hear the rest of it.

Here is how I generally envision it happening without new hooks in the MessagePort spec:
```
Return a MessagePort `MP1`, which is entangled to the MessagePort `MP2` in the captured app.
[...]
Run the [severe connection algorithm] if any of the following happens:
* The capture session ends.
* If the user ever instructs the user agent to change the capture source.
* If the top-level document of the captured application is navigated cross-page.
```

Where the `severe connection algorithm` roughly consists of:
```
* Disentangle the ports.
* Queue events on both sides to inform the relevant apps that the ports are invalidated.
```

> About 4 and 5, it would be good to get use cases to motivate this.

The capturer knows when it's capturing X.
The capturer knows if the capture session is stopped, either through the capturer's own action or the user's.
Through Capture Handle's existing events, the capturer even knows when the capturee changes.
But the capturee doesn't know any of this.

So to name just one use case to motivate 4 and 5 - once a channel is established, the **capturee** might expose user-facing controls to produce action in the **capturer**. ("Start recording; stop recording; save to disk; discard recording.") Such user-facing controls would have to be hidden away when they become inactionable, which is the case when the capture-session stops.

> 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.

Same class, not same object. I don't see it as an issue. Do you?

> 9 is not about behavior but about ergonomics.

The level of complexity in the app code to handle navigation of the captured-tab would be staggering, and race-prone. This goes beyond mere ergonomics.





-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1479835248 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 15:56:00 UTC