Re: [mediacapture-handle] Use postMessage pattern for two-way messaging. (#69)

The first broadcast API has some benefits:
- The model is cleaner, we attach it to CaptureController for instance instead of the track.
- We reuse known events/known patterns on capturer side.
- We enforce an origin contrary to capture handle (via MessageEvent.origin . 

It also has some downsides:
- It is a replacement to an existing API, no new functionality really.
- The implicit message to cache on capturee side so that new capturer can get the event is not really aligned with postMessage and seems surprising/a bit awkward.
I think we should consider bringing the benefits of this approach (enforce origin, move to CaptureController).
I am less sure about reusing postMessage though.
Another approach to look at is something like HTML History state (which is using structure clone, like we could do for capture handle). This seems closer to what we are trying to model.

As of the second API, I like the fact it tries to be minimal.
The main difference I see compared to my past suggestions is that capturer.onmessage can happen for any capturer.
There is no way to understand/ensure that two successive messages are coming from the same capturer. This might be error prone (although rare in practice).
That is the main reason I suggested in the past an API where a capturer would be represented as a single event on capturee side (only sent when capturer decides it wants to talk to capturee), and a MessagePort would be directly created for actual communication.
Given we now have CaptureController, my past suggestion would be something like:
```
// capturee
navigator.mediaDevices.onDisplayCapturer = e => recognize(e.origin) && oneOn1Port = e.port;

// capturer
captureController.captureePort().postMessage(...);
```

One area to study before we try to dive into APIs is what happens when capturee navigates to a new document (or navigates back to a previous document using B/F cache). Maybe this should be somehow modelled into the API. MessagePorts are not great at knowing that the guy you are talking to is actually gone.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/69#issuecomment-1306852755 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 8 November 2022 08:55:42 UTC