- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jan 2022 20:36:20 +0000
- To: public-webrtc-logs@w3.org
Thank you for these proposals, @youennf.
---
> 1. MediaSession-based communication.
This is an interesting proposal. I have saved for later some nits, so as to focus first on the general thrust. The propsal takes great pains to latch onto an existing mechanism (MediaSession). It's not immediately clear to me what is gained by making that design decision. Could you please explain?
As for the drawbacks I can see:
* It creates a dependency on MediaSession.
* It seems more complex than the alternative of a simple bespoke API.
* It brings into the mix MediaSessionActions which are less relevant given the context (e.g. togglecamera, hangup).
* Even actions which are relevant for both contexts, are awkwardly phrased for the new one ("nexttrack" vs. a generic "next").
* It makes it hard to extend with actions that are relevant for our context, but are not relevant for the MediaSession context.
Would love to hear more of your thoughts, as well as those of @jan-ivar.
---
> 2. MessageChannel-based communication
I'd rather steer clear of this.
On the one hand, it requires tight cooperation, or else how would the capturer/capturee understand each other? So we can take it as a given that users of this API would be **tightly integrated**.
On the other hand, it forces a communications method, and I think this should be left out of scope. **Tightly integrated** applications have their own various means.
--
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-1016847526 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 January 2022 20:36:21 UTC