- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Feb 2022 09:25:54 +0000
- To: public-webrtc-logs@w3.org
The actions proposal is based on interest from 'capturer', I haven't heard any interest from 'capturee'. That puts this API at risk. To be successful, this API should be as good if not better than the out-of-band approach 'capturee' are apparently planning to use. Piggy backing on MediaSession is a way to reduce the adoption risk/burden as this is an adopted API, provided we can find the right security model. > I do not believe it makes sense to **force** two applications As I said, this gives the choice, existing communication channels can continue to be used. > to now support a new method of communication. It is not a new method, it is reusing a well known web pattern between two entities that do not trust themselves deeply (cross-origin iframes or opener/openee) > But for the MVP, a simple string is enough. AIUI, it is not a simple string, it is a string + an origin + an event. This makes it very close to postMessage, albeit transfer. If we think we will add postMessage communication level, I do not see why we should support the string API. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/166#issuecomment-1029796740 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 4 February 2022 09:25:56 UTC