- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Jun 2021 15:33:51 +0000
- To: public-webrtc-logs@w3.org
Sorry if I was not clear, I was trying to express the granularity of use case complexity. These are thoughts that I was hoping would help but this is not the case apparently :( Overall, I do not have a solid view on a proposal, hence why I am trying to start with a small-but-still-useful proposal. Here is another idea, not thought out at all but anyway, it at least helps illustrating the diversity of API that could be used. If the end-goal is to support complex synchronisation use cases, why not directly expose a MessagePort on the capturing context entangled to another MessagePort exposed on the captured context, instead of an ID. Captured page needs to opt-in for the port to be exposed on the capturing page through an opt-in API. It is then up to the capturing context, knowing the captured context origin, to decide whether it wants the entangled port to be exposed to the captured context (exposed for instance through a callback given to the opt-in API). To support navigation usecases, a new set of ports would be created when the opt-in API is called in the post-navigation captured context. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-852222856 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 June 2021 15:34:12 UTC