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

> postMessage can allow this naturally, if we decide so.

That's the capturer->capturee direction. But we want bidirectional messaging, which requires a MessagePort be posted back. And since this will just be a normal run of the mill MessagePort - since we don't atm have any other one - then it won't exhibit this special behavior.

But if we expose a new MessagePort through a getter, we can specify in the getter itself this new behavior. We don't need to modify MessagePort itself.

> MessagePorts are transferable so there is no guarantee that the message will be processed by the capturing application.

Transferring the port is delegating; I see it as equivalent to relaying the messages themselves. What my proposal guarantees is that the messages will only be transmitted as long as the capture session is active.

> The postMessage approach gives us more flexility here. If we want to, we can decide to enforce this rule without any race conditions.

Could you help me understand why the approaches are different wrt races? Do you mean that if a task starts executing before the session-capture stopped, then `postMessage(x)` will deliver `x` even if the session-capture ends while the task is executing? If so, I don't see it as desirable, since tasks can run arbitrarily long.

> Before diving into API shape, it would be good to nail down the exact behavior we want.

1. Bidirectional messaging.
2. The capturer initiates.
3. Distinct capture-sessions lead to distinct channels.
4. The channel is transient - it becomes invalidated if the capture session ends, or if capture-session is retargeted (e.g. share-this-tab-instead).
5. Both sides get events informing them of invalidation. (Can easily avoid doing work to put together messages that won't be delivered.)
6. [Known non-issue] Transient channels can be used to establish permanent ones (through posting a regular MessagePort).
7. Sender can limit the origin to which the message will go. (On either side.)
8. Receiver can detect which origin the message came from.
9. Capturing apps that comprise multiple iframes from multiple origins, can easily move the ownership of the tracks and their associated communication channels, and do not need to resort to cumbersome internal messaging. ("Please send this to the capturer if it has not changed since you have last informed me that it was ${origin}, which was ${notification_num} from my perspective.")


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