Re: [mediacapture-handle] Should the handle be an object? (#68)

TL;DR: I don't think `handle` should be an object, as this seems like a design break.

captureHandle.[handle]( was billed as an _"identity"_ string for _"[Bootstrapping]("_ _"[a connection]("_ [[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

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 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 18 October 2022 22:14:13 UTC