- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 07 Nov 2022 22:20:20 +0000
- To: public-webrtc@w3.org
jan-ivar has just created a new issue for https://github.com/w3c/mediacapture-handle: == Use postMessage pattern for two-way messaging. == We need a _"[a rudimentary messaging API](https://w3c.github.io/mediacapture-handle/identity/index.html#use-case-1)"_ to overcome storage partitioning. We also need to stop reinventing postMessage in #11 and #68. I'm proposing postMessage-shaped APIs for both directions: 1. **capturer ← capturee**: Replace the cross-origin info-surfacing "handle" and "permittedOrigins" which [reinvent postMessage](https://github.com/w3c/mediacapture-handle/issues/11) 2. **capturer → capturee**: A one-way postMessage that takes transferables (like e.g. a port!) ### What is postMessage? It's the web's API pattern for cross-origin communications. All APIs that expose information to realms of other origins have this shape today, except for this spec. It's a pattern, because there's no single postMessage, but three: - (one-to-one) [MessageChannel](https://html.spec.whatwg.org/#messagechannel) - (one-to-many) [BroadcastChannel](https://html.spec.whatwg.org/#broadcastchannel) but same-origin (no transferables) - (one-to-any) [window.postMessage](https://html.spec.whatwg.org/multipage/web-messaging.html#dom-window-postmessage-options-dev) with targetOrigin But none of them fit exactly, because... ### The capture comms problem is unique There can be more than one capturer, and we'd like the capturee to remain unaware unless contacted. A fourth type, a mix of the last two, seems needed: a cross-origin broadcast-like channel. Capturees also need to communicate _ahead_ of capture. This led to the current API which acts like publishing ahead of capture, and like postMessage during capture. But a postMessage shape can solve this too. ### The proposed API A _capturee_ would have a `mediaDevices.capturer.postMessage(msg, "*")` that broadcasts to all capturers. Since it doesn't take transferables, all messages are clonable, so it _caches the last message posted, and surfaces it on future capturers!_ — This lets the capturee surface whatever info it likes (ids, handles, crop targets) to present _and_ future capturers. Both present and future capturers are also updated the same way (by posting a new message). The _capturer_ can send messages directly to the capturee. With this, exchanging a 1-1 port becomes trivial: ```js // capturee navigator.mediaDevices.capturer.postMessage(msg, "*"); navigator.mediaDevices.capturer.onmessage = e => recognize(e.origin) && oneOn1Port = e.port; // capturer captureController.onmessage = e => { if (recognize(e.origin)) { const {port1, port2} = new MessageChannel(); oneOn1Port = port1; captureController.postMessage(port2, {targetOrigin: e.origin, transfer: [port2]}); } }; ``` This new API as shown is on [CaptureController](https://www.w3.org/TR/screen-capture/#dom-capturecontroller), which would also solve https://github.com/w3c/mediacapture-handle/issues/12. Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/69 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 7 November 2022 22:20:22 UTC