- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Thu, 10 Jun 2021 09:11:45 +0200
- To: Elad Alon <eladalon@google.com>
- Cc: WebRTC WG <public-webrtc@w3.org>
- Message-ID: <CA+ag07Zgc64gV828NfQm2_mc3TCcm4U9who+Qr18Rg=FjCatmg@mail.gmail.com>
Hi Elad, I find this API really interesting and I can understand the value for google and other service providers. However, it is unclear what is the benefit for the rest of the community. Let me explain my concerns. Given that the method are opt-in, I foresee that only the web sites interested in being captured will ever use this API, and given that the the web sites can set the domains that will be allowed to receive that information, it is not unreasonable to think that they will only allow for the same company VC products. So my worries are that we will end up having an API that will be only enabled in google docs to be able to expose information to google meet, and in microsoft 360 to expose information to microsoft teams, and they will be able to provide a much better presentation experience than the rest of VC services. I am not saying that these are Google or Microsoft intentions, but that is a more than feasible possibility. I understand the value of an API like that, but I think it should be a benefit for all, not just for the ones that control both the content and the conferencing services. I really hope that the API can be modified so this can happen. Best regards Sergio El mar, 8 jun 2021 a las 16:23, Elad Alon (<eladalon@google.com>) escribió: > Hello all, > > An existing issue with screensharing is that the capturing app cannot > easily discover which application is being captured, even if the captured > application wishes to expose this information. Are you tab-sharing a > Wikipedia page or a presentation? If a presentation - what is its session > ID? The capturing application does not know. And what a shame that is! For > if the capturing application knew what it was capturing, it could establish > out-of-band communication with the captured application and request the > next slide, next article or anything, really, without forcing the user to > switch tabs back and forth. > > *Capture Handle* is a feature that solves that problem. I've started Discourse > thread > <https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354/> on > the WICG. There's also an explainer > <https://docs.google.com/document/d/1oSDmBPYVlxFJxb7ZB_rV6yaAaYIBFDphbkx5bXLnzFg/edit?usp=sharing> and > a spec-draft <https://eladalon1983.github.io/capture-handle/>. > > This feature is available for *Origin Trial in Chrome beginning with m92*. > > Please send me feedback in whichever way you find most convenient. > > Thanks, > Elad Alon >
Received on Thursday, 10 June 2021 07:13:26 UTC