DRAFT: collaboration concept #12677
DRAFT: collaboration concept #12677
Conversation
| @@ -0,0 +1,137 @@ | |||
| # Collaboration Concept | |||
|
|
|||
| ## Microsoft VSCode Live Share Extension | |||
There was a problem hiding this comment.
"VS Code offers collaboration support via the official Microsoft Live Share Extension. It offers the following features:"
At the end it would be nice to mention that we can't reuse the same protocol nor offer the same API to extensions because both have a proprietary license.
There was a problem hiding this comment.
As far as I know, APIs cannot be licensed, only the implementation. If we were to offer a drop-in replacement for Microsoft's vsls that uses our custom collaboration feature implementation, we shouldn't infringe on any license agreements (fair use). See also Oracle v. Google.
| @@ -0,0 +1,137 @@ | |||
| # Collaboration Concept | |||
|
|
|||
There was a problem hiding this comment.
I would start with a short motivational and overview, e.g.
"Collaboration is an often asked for feature in Theia. In this document we analyze the collaboration feature of VS Code, specify technical requirements and architecture for Theia and give an overview over the API concept."
collaboration-concept.md
Outdated
| - Mechanism for making the API available to other extensions, see [vsls](https://www.npmjs.com/package/vsls) | ||
|
|
||
| Similar to the tunnel feature, the connection between host and other users is accomplished using hole-punching. | ||
| I.e. a single central server serves as an intermediary to exchange messages. No messages are being exchanged directly between users. |
There was a problem hiding this comment.
According to the docs they do send messages directly between host and users if the network allows it, see https://learn.microsoft.com/en-us/visualstudio/liveshare/reference/connectivity#connection-modes. However every connection is authenticated via the cloud, so it's never fully private.
| 2. Virtual File System coming from the host user | ||
| 3. Frontend message proxying for debug sync (i.e. debug launch or monaco language service requests need to be proxied to the plugin host and the results send back) | ||
| 4. Terminal input + output syncing requires a yjs like approach for input and a broadcast for output | ||
| 5. Broadcast required for Chat functionality |
There was a problem hiding this comment.
Should we also list other potential requirements like:
- privacy (e.g. allow to configure an own message server without going through one central public instance)
- encryption
- authentication
- extensibility (for customized messages between plugins, similar to what VS Code offers)
There was a problem hiding this comment.
Thank you very much! This sounds very exciting!
Did I get that correctly that your example for the API concept is code that is expected to live in a Theia frontend extension? Is my understanding true that
- any frontend extension can listen to and send requests, notifications, and broadcast messages
- the frontend extension can then decide whether to directly process those messages or whether to forward this to the plugin host via main/ext communication?
- there is a generic forwarder to the plugin host to support VS Code extensions that use the vsls API? If yes, how do we determine when to forward and when we don't, or do we forward all messages and the vsls API clients would decide whether to react?
Thanks again! Awesome initiative!
Yes.
Depending on permissions (which I only mentioned in here). The frontend should reject any impermissible action.
Right 👍
Good question, haven't put too much thought into that yet. First thought would be to have some sort of message wrapping, but not too sure. This is probably one of the last features that I plan to implement anyway. |
| Similar to the tunnel feature, the connection between host and other users can be accomplished using hole-punching. | ||
| I.e. a single central server serves as an intermediary to exchange messages. No messages are being exchanged directly between users. | ||
| If possible - for example, if the users are on the same network - the extension will try to connect directly to the host, | ||
| see [here](https://learn.microsoft.com/en-us/visualstudio/liveshare/reference/connectivity#connection-modes). |
There was a problem hiding this comment.
I don't understand the "i.e." following the mention of "hole punching" as this term means establishing a direct connection through each peer's NAT by "punching holes" with the help of an intermediary server to know where to hit. I've also successfully managed to do hole punching in the past using UDP while TCP was more finicky (still worked). The implication means we'd need a UDP transport for direct connections? But that's only if you truly want to do hole punching over the internet.
There was a problem hiding this comment.
Hole punching might not be the correct term here, right. In the end, all that we need to accomplish is that users can communicate with each other through some means, be it some intermediary server or whatever.
There was a problem hiding this comment.
Fine if your goal is to abstract the API from how the communication might happen. Although properly laying down the expected modes of communication would help in designing said API: P2P vs Server-centric, how to handle auth/identity/permissions, etc...
If the goal is to be highly generic then the act of creating sessions must be defined at least partially by the embedding layer for the target IDE:
- Define the communication implementation (a.k.a "driver"? i.e. connect to some server and request a new room)
- Said driver may implement auth (i.e. prompt the user for credentials in the IDE? defer to some OAuth service?)
| Assuming the server is built specifically for Theia, we can reuse some of Theia’s dependencies for this, i.e. socket-io for bidirectional, high-performance messaging on top of HTTP. | ||
|
|
||
|
|
||
| ## API Concept |
There was a problem hiding this comment.
What kind of API are we talking about here? Theia Extension API? VS Code Extension API?
Should we inject the vsls package the same way we do with the vscode API so that extensions relying on this package can work in Theia?
Should we take care to properly implement the groundwork feature in the framework before exposing it through the plugin API? (By contrast with webviews which are baked-in the plugin-ext package at the moment.)
There was a problem hiding this comment.
What kind of API are we talking about here? Theia Extension API? VS Code Extension API?
Neither, the collaboration messaging infrastructure should be implemented independently of Theia (maybe another Eclipse project?) so that it can be reused for other IDEs as well. The API concept provided in here is for a general JS/TS library that can be used in Theia.
Should we inject the vsls package the same way we do with the vscode API so that extensions relying on this package can work in Theia?
Yes, that would be the mid-term plan. I wouldn't try to introduce a new Theia-only API to the plugin-ext. We should aim to replace the vsls package in the plugin host.
There was a problem hiding this comment.
Then is it fair to assume that this library must support at least what vsls supports? That would make for a good starting point when designing the API.
|
For anyone interested: I'm currently working on a PoC for this, the communication infrastructure is working as designed in this document and I've got workspace sharing and editor sync already in a working state: 2023-08-10.16-10-06.mp4 |
|
Thanks everyone for the valuable feedback. This has been superseeded by #13309. |
What it does
DO NOT MERGE THIS!
This PR provides a platform for discussion on the proposed collaboration feature. It will be followed up by a PR that actually implements this concept.
Please comment if you have any critique or questions with the approach outlined in the document. I'm happy to discuss, revise and extend the concept.