Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Live collaboration capabilities #8286

Open
slemeur opened this issue Jan 12, 2018 · 25 comments
Open

Live collaboration capabilities #8286

slemeur opened this issue Jan 12, 2018 · 25 comments
Assignees
Labels
kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. roadmap/1-year Epics that are planned to complete in the short term (12 months or more)

Comments

@slemeur
Copy link
Contributor

slemeur commented Jan 12, 2018

Description

Motivations

Over the past years, we did different prototypes showing pair programming within Eclipse Che. At the end of 2017, few announcements have been made by other IDE/editors:

We have always envisioned live collaboration with Che to be enable between different tools. So one developer could be using Che and another could be using Eclipse IDE or another. Our first prototypes were made with Eclipse Flux: https://github.com/eclipse/flux.

We would like to leverage Teletype inside of Eclipse Che in order to provide live collaboration capabilities.

For this work, we will target the next gen Che. See #8266.

Pair programming

The pair programming should allow multiple developer to code on the same file.
The integration in the editor will allow the users to the cursor of each other users. It will be possible to hover the cursor to show who is the user behind it.

The integration in the IDE will consider adding an action to start and share a teletype session from Che and connect of a Teletype session started outside of Che.

Debug session

The live collaboration, will allow to share a debug session with other users.

  • A user is sharing his debug session with other users
  • When the user is getting at a break point, the breakpoint (and code) will be highlight in the editor of all users
  • All users, who are sharing the debug session are able to do actions on the debugger, to resume, pause, stop, step into, step over.
  • All users have access to the debugger, see the variables, see the stacktraces and the browse the different threads.

Operational transformation

Live collaboration could lead to collision and we should be looking at integrating an operational transformation engine.

Linked Issues

redhat-developer/rh-che#438
#3080
#4474
#5329

@slemeur slemeur added the kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. label Jan 12, 2018
@sunix sunix self-assigned this Jan 18, 2018
@MahatmaFatalError
Copy link

Are there any news to share here?

@sr229
Copy link
Contributor

sr229 commented Dec 2, 2018

I think we can further extend this by adding User Roles within a workspace, which grants them specific actions in the workspace. This is proven effective with Cloud9's Live Collab

@bdeleonardis1
Copy link

Any update?

@slemeur
Copy link
Contributor Author

slemeur commented Mar 12, 2019

This is still an epic that we would love to address, but has right now a lower priority regarding the other aspects we are working on.

If someone in the community is willing to help, that would be awesome!

It has also been proposed as a topic for the Google Summer Of Code for 2019:
https://wiki.eclipse.org/Google_Summer_of_Code_2019_Ideas#Topic_1:_Co_Editing

@sunix : has been experimenting on this area since quite long time and he has deep understanding. He should be the point of contact.

@bryantson
Copy link

Is there any update on this?

@sr229
Copy link
Contributor

sr229 commented Aug 21, 2019

last activity was around a year ago, Probably everyone forgot about this....

@sunix
Copy link
Contributor

sunix commented Aug 22, 2019

Hello we are working on this: @Rijul5 has started to work on a vscode extension that is using teletype libraries and would work on Che ... as part of the Google Summer of Code. He is trying his best to have something working at the moment.

@m-hu
Copy link

m-hu commented Aug 22, 2019 via email

@bryantson
Copy link

So, with Che 7/CRW 2.0, this wouldn't be released, correct?

@sr229
Copy link
Contributor

sr229 commented Aug 23, 2019

@sunix when can we expect a working draft/Beta and source release?

@sunix
Copy link
Contributor

sunix commented Aug 23, 2019

We will release this as soon as this will be ready. It will be coming as a Che7 plugin indépendant from Che7 release process: would be available in the market place.

@sr229
Copy link
Contributor

sr229 commented Sep 11, 2019

We will release this as soon as this will be ready. It will be coming as a Che7 plugin indépendant from Che7 release process: would be available in the market place.

That would absolutely amazing, let us know if there's a working draft available - this will go really hand in hand with people who prefers VSCode/Web over Theia.

@bryantson
Copy link

@sunix Sounds great.

@che-bot
Copy link
Contributor

che-bot commented Mar 11, 2020

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 11, 2020
@che-bot che-bot closed this as completed Mar 18, 2020
@sunix
Copy link
Contributor

sunix commented Mar 20, 2020

Still in progress, @Rijul5 is going to show us his progress during the next community call

@sunix sunix reopened this Mar 20, 2020
@sunix sunix added status/in-progress This issue has been taken by an engineer and is under active development. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Mar 20, 2020
@sunix sunix assigned sunix and unassigned sunix Mar 20, 2020
@traveling-developer
Copy link

Hi @sunix any updates on this?
Thanks 👍

@sunix
Copy link
Contributor

sunix commented Jul 30, 2020

@Rijul5 is still working on it. ATM stuck in having his extension working in a container. @yudansha interested to give a hand? :)

@patlachance
Copy link

@Rijul5 is still working on it. ATM stuck in having his extension working in a container. @yudansha interested to give a hand? :)

Any progress on this feature?

@gattytto
Copy link

gattytto commented Dec 18, 2020

I can successfully build the vsix but as I see it (yet haven't tested it) this requires a node CLI dockerImage container running a postgres server and a node sidecar for the extension which has the teletype-client connecting to localhost to the cli postgres.

@sunix have you tested this before? there's ~6 months of idle time in the extension repo tho it'd be nice to use this from RH-devsandbox to che-osio and home barebone minikube

@mbenitez1607 mbenitez1607 removed the status/in-progress This issue has been taken by an engineer and is under active development. label Jan 19, 2021
@sunix
Copy link
Contributor

sunix commented Jan 20, 2021

Last time i tried the extension, it was failing to run inside a che container. but was working fine in vsix. I am still wondering if this is the right approach: Teletype is using webrtc, and in the prototype, it is trying to run a headless browser to have access to it. I did not have time to investigate the problem. Maybe we should reconsider the approach and use either a Theia plugin that would run in browser. or a Theia extension with the browser component. Also I am not sure about the reliability of having it as a vscode ext.

So I would recommend that we work on a Theia extension or plugin, browser side to quickly produce a POC of a Teletype guest client. Would be something similar to what we had for that demo we have done with Che6.

Some ideas for the next steps to take in consideration that we don't want to share the workspace (no terminal access to the workspace): we could start a theia container with limited features but these ones could only participate in editing the files open by the host and main che-theia IDE.

@sr229
Copy link
Contributor

sr229 commented Mar 21, 2021

Last time i tried the extension, it was failing to run inside a che container. but was working fine in vsix. I am still wondering if this is the right approach: Teletype is using webrtc, and in the prototype, it is trying to run a headless browser to have access to it. I did not have time to investigate the problem. Maybe we should reconsider the approach and use either a Theia plugin that would run in browser. or a Theia extension with the browser component. Also I am not sure about the reliability of having it as a vscode ext.

So I would recommend that we work on a Theia extension or plugin, browser side to quickly produce a POC of a Teletype guest client. Would be something similar to what we had for that demo we have done with Che6.

Some ideas for the next steps to take in consideration that we don't want to share the workspace (no terminal access to the workspace): we could start a theia container with limited features but these ones could only participate in editing the files open by the host and main che-theia IDE.

Considering Theia supports VSIX nowadays I think it's better to make it a VSIX instead and let the IDE container run the client under the hood.

@l0rd l0rd added the roadmap/1-year Epics that are planned to complete in the short term (12 months or more) label Mar 26, 2021
@sunix
Copy link
Contributor

sunix commented May 29, 2021

for your information, today, we started to work again on the co-editing/pair programming extension that @Rijul5 has started some times ago. With @demsking as part of https://paris2021.hack-commit-pu.sh/. WIP is here https://github.com/demsking/vscode-teletype-guest/commits/dev We starting a new approach to avoid running webrtc in node: running the whole teletype client in a webview. I hope it will work, we will continue working on that during our free time.

@che-bot
Copy link
Contributor

che-bot commented Dec 6, 2021

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 6, 2021
@che-bot che-bot closed this as completed Dec 13, 2021
@gattytto gattytto removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 14, 2021
@svor svor reopened this Dec 15, 2021
@azatsarynnyy azatsarynnyy added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Dec 15, 2021
@Deel96
Copy link

Deel96 commented Sep 15, 2022

Hi,
what is the current status of live collaboration?
Best Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. roadmap/1-year Epics that are planned to complete in the short term (12 months or more)
Projects
None yet
Development

No branches or pull requests