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

> 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).

I have not understood this message.
In both cases one side sends the first message.
* If we expose a string from the capturee on the capture-handle the capturer sees (my proposal), the capturee effectively sends the first message.
* If we expose a MessagePort on the capture-handle, the capturer sends the first message.

In both cases, it is necessary for both sides to agree on how messages are structured. It's equally true in both cases, and therefore the **tightness** of collaboration assumed is the same.

> 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.

I do not believe it makes sense to **force** two applications that are already communicating using tried-and-true mechanisms that were produced by expensive-to-employ engineers, to now support a new method of communication. **Enable** - great, let's bookmark the idea of adding a MessagePort to the capture-handle API, and circle back to it when it's time for improvements. But for the MVP, a simple string is enough.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-1028922859 using your GitHub account


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

Received on Thursday, 3 February 2022 12:04:52 UTC