El jue, 10 jun 2021 a las 20:25, Elad Alon (<eladalon@google.com>) escribió: > Hi Sergio, > > *Concerning Capture Handle:* > The space of web-based VC applications is constantly growing, as is that > of Web-based productivity suites. What's preventing Jitsi from using this > feature to set up collaborations with applications like Google Docs, MS > Office, or any other productivity suite? > That's not up to Jitsi to decide, but it will be up to google docs/ms office to allow jitsi domains to communicate with them. Also, what will happen with self-hosted jitsi servers that would have their own domains, or not domains at all? > What's preventing Jitsi from producing their own productivity suite and > integrating with it using Capture Handle? > ... > No feature is equally useful to all players on the Web. Screen-capture is > paramount to VC applications, but of little use to airline booking systems. > Even if Capture Handle is more easily employed by entities who sit on both > sides of the seesaw (capturer+capturee), that is not a valid argument > against it. (a) The feature is still very useful for those who only sit on > one side, so long as they collaborate with the other side. (b) The > use-cases for those who sit on both sides are legitimate enough a need for > us to support them. > The web apis are useful for an use case, what this web API will create is an uneven playfield to VC applications. I am not against it per se, but this should be clear to everyone and don't pretend otherwise. > > *Concerning the Actions > <https://w3c.github.io/mediasession/#actions-model>-like alternative:* > I think that's an interesting approach that could be explored in tandem. > It provides a complementary set of capabilities for use-cases that benefit > from the rails it offers, while other applications need the freedom of > Capture Handle. > > 1. The Actions-like approach limits collaboration to a closed set of > predefined actions. The Capture-Handle-based approach bootstraps arbitrary > APIs. > > So Jitsi will have to implement google docs apis, ms office apis, to do basically the same? doesn't seem very scalable > > 1. The Actions-like approach would not easily support non-trivial > authentication. What if the captured application has privileged actions to > expose? > > That's what I am concerned about, privileged actions that will allow certain VCs to have a better user experience than the competence. > > 1. Would it expose it to any capturer? Or any capturer from a given > origin? Many applications will need more fine-grained access-control > (specific account, not just specific domain). Think remotely editing > content on the captured document. With Capture Handle, apps are free to use > any authentication method, as we only bootstrap their communication, we > don't serve as their telco. > > If you want to do that, why not integrate the VC application into your document web page and not the other wise? > > 1. The Actions-based approach does not help detect self-capture and > its awful result - the hall-of-mirrors. Capture Handle does. > > A capture-sef: disabled property on the getDisplayMedia would prevent this as well. > > 1. The Actions-based approach does not support discovery of captured > origin, which is useful for analytics - VC applications want to know what > their users share, so as to approach the right partners for collaboration > using Capture Handle. That is a legitimate use-case even if the analytics > gathered are incomplete due to lack of opt-in from some sites. > > That part of the api could work as is, i am only against the privileged apis for certain domains. To conclude this email (*not* the conversation 😜): > I hope to convince you that Capture Handle is very useful to Jitsi. If > it's a bit more useful to X than to Jitsi, I don't think that's a valid > complaint. > My concern is that it will provide no value to Jitsi but will help create monopolies to VC+content providers. I would be happy to collaborate in the future on complementary solutions > that offer something similar, but with sufficient added value ("rails"); > the Actions-based approach you and Youenn have brought up sounds like that > to me. > I think that the action based approach is a good way to go for the remote presentation actions, let's see if we can get an agreement on the other topics. Best regards SergioReceived on Thursday, 10 June 2021 19:07:05 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 10 June 2021 19:07:29 UTC