- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Oct 2022 22:14:11 +0000
- To: public-webrtc-logs@w3.org
TL;DR: I don't think `handle` should be an object, as this seems like a design break. captureHandle.[handle](https://w3c.github.io/mediacapture-handle/identity/index.html#dom-capturehandle-handle) was billed as an _"identity"_ string for _"[Bootstrapping](https://w3c.github.io/mediacapture-handle/identity/)"_ _"[a connection](https://w3c.github.io/mediacapture-handle/identity/index.html#generic-problem-desc)"_ [[1]](https://w3c.github.io/mediacapture-handle/identity/index.html#use-case-1): > The means for transmitting these messages are outside the scope of this document. Some options are: > > * Shared cloud infrastructure. > * Messaging via a worker. (Note: Storage Partitioning might disrupt this option.) > * A rudimentary messaging API might be added expressly for this purpose. Letting `handle` accept serializable objects doesn't fit with that design, and takes us instead another step closer to reinventing postMessage, which I warned about in https://github.com/w3c/mediacapture-handle/issues/11. If storage partitioning has made out-of-band messaging nonviable, CropTargets aren't serializable, and we're trying to send objects through` handle`, then we seem overdue for the third option IMHO... a rudimentary messaging API. A way forward on that might be: 1. Address https://github.com/w3c/mediacapture-handle/issues/11 first 2. Move captureHandle to captureController first to avoid message fan-out so we don't spam every track 3. Specify a port on each captureHandle and a specialized port somewhere on the capturee side that caches the last message sent on it ahead of capture, to surface it on the captureController upon gDM success. If the capturer never responds, then the capturee never learns it's being captured. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1283068158 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 October 2022 22:14:13 UTC