Re: [mediacapture-screen-share] Identification of Captured Application By Capturer (#166)

> MediaSession is a rich spec that offers much more than sending simple actions. I think the duplication of work is quite minimal. I have not yet heard what entanglement with MediaSession would improve.

If we go with actions like next slide, previous slide, capturer might want to understand whether:
- these actions are supported or not (say we are at the end of the slide show)
- when calling an action, understand when the action is actually executed.

We could try to be very restricted in terms of actions, my gut feeling is telling me people will want more than that.
And the "more than that" will be more and more redundant with MediaSession.

> Looks pretty one-way to me. See explanation above. Each part (Identity, Actions) produces a distinct one-way communication channel. These APIs (Identity, Actions) are useful both in isolation as well as together. One session can involve one, the other, neither, or both.

Identity provides a de facto a one-way communication channel.
As you explained during last meeting IIRC, it can be used to create a two-way communication channel using server-side logic.

Actions also provide a two-way communication channel:
- capturee exposes the actions it supports
- capturer trigger some actions

> I think the onus is on you to show it's desirable to add a generic messaging channel where a limited one would do.

IIRC, in a past WG meeting, you stated that, in some cases, the goal is to create such a messaging channel, either through a network intermediary or through something like RTCPeerConnection.

If we believe this is something desirable, direct support through postMessaging seems a better option to me.
It is simpler, more reliable, more efficient, more powerful and probably more secure.
As an example, a capturee could postMessage a CropTarget to capturer which would use cropTo.
Another example: If RTCPeerConnection is used, who says local networking will always work.

> @youennf, I believe these two lines contradict each other. The second line explains the necessity of a mini-protocol for both approaches (my Identity, your [MessageChannel-based communication approach]( Namely, that even if the mini-protocol is as simple as a stringified JSON with a single key-value pair, e.g. `{name: "Wikipedia"}`, this is something that the capturer must understand.

The capturer/capturee approach is like a client/server approach: server/capturee defines the protocol, client/capturer has to abide to it. Server/capturee may or may not restrict client to specific origins.
What I am meaning by less tight cooperation is that, with your proposal, there is server-side collaboration required.
With server-side collaboration, capturer will send some identity to capturer service, which has to generate some form of identity proof to the capturee service to do pairing. This identity proof is not needed in case UA internal communication is used (there is a single user using the UA).

> When applications share a cloud infrastructure, it might be preferable for the developers to go through some **pre-existing** RESTful API

This does not seem contradictory to me: the same RESTful API can be used to validate or not the request to open a channel with a capturer.

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

Sent via github-notify-ml as configured in

Received on Wednesday, 2 February 2022 09:55:01 UTC