Re: [mediacapture-handle] Don't reinvent postMessage (#11)

> no other cross-storage message channel exists in the platform today

If I have missed the part of [BroadcastChannel.postMessage]('s specification that forbids cross-tab communication, as of 2022-03-14, please help inform me.

> I don't see who'd bother setting up the 2. if they can send local cross-storage instructions munged into setCaptureHandleConfig().

1. This communication channel would be single-direction, which is why it would not be as useful, which is why applications would generally need something more. (It's also in the already available direction - that in which pixels flow.)
2. BroadcastChannel and shared workers are still a thing.
3. Natural users of REST-like approaches would be those who already have a shared login identity for the user and communicate other state, e.g. "user changed preferences" or "user logged out".

> but seems deserving of a proper solution, not a hack like this.

I think this **is** a proper solution, and NOT a "hack".

> I've not been impressed by other use cases mentioned offline, which included getting info to the capturer in time for the proposed "conditional focus" API.

I am sorry to hear that you were unimpressed. But I maintain that these are important use-cases, and I know Web-developers who would attest as much.

> Maybe a shared controller object like in #12 (comment) could bring these things together?

I don't see how that would work. (Also, `controller` does not have support in the WG at the moment.)

> I'd prefer single-use to start.

What information could theoretically change your mind?

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 14 March 2022 10:32:55 UTC