3 ms·
Hi - I am the project lead for Eclipse Che. While I'd love to take credit for a special API for handling intellisense with languages, we didn't do it alone. W
by TylerJewell 10y ago
Hi - I am the project lead for Eclipse Che. While I'd love to take credit for a special API for handling intellisense with languages, we didn't do it alone. We had a proprietary API that we built over a number of years that distributed intellisense using JSON. But when we saw Microsoft's VS Code doing something very similar but for local services, we consolidated into a single "Language Server Protocol" that we announced with Microsoft and RedHat earlier this year. This allows any IDE to plugin to any language. Languages have to provide their own language server implementation that matches the JSON protocol.
In Eclipse Che, we package these language servers for distribution into dynamically deployed agents. so when you start a workspace, your workspace can add a "PHP agent", for example and then we will deploy the language server and then hook up the browser IDE to the language server. To the end user, it feels seamless, but we actually install the language server for them. There are something like 2 dozen languages being built for language servers now. Rust just announced theirs and others are working on C/C++/RAML - even Emacs is getting one. RedHat is working on an advanced Java version and we use CSharp and eventually typescript from Microsoft. We want total interop with VS Code. Eventually Eclipse Orion (an editor) and Eclipse IDE (desktop IDE) will add support.
With Eclipse Che, we provide a simple CLI that lets you live sync your workspace to your desktop IDE. You just "che mount" and we use a fuse-based file system with unison sync to keep the hosted workspaces synchronized with the desktop. You can then use your local IDE and still have your workspaces entirely in the cloud.
These language servers must have access to the project file system, and we are handling that by either embedding the language server into the same container as the workspace, but since we now support compose workspaces where a workspace can be many containers, we are moving all of the language servers to run as separately deployed agent containers. When a user requests a language intellisense, we'll deploy for that workspace an agent container which is volume mounted to the projects in the workspace containers, so that the workspace can have the utilties needed.
- sytse 10y agoThanks for the background Tyler. The Language Server Protocol is certainly interesting. We've linked this comment from https://gitlab.com/gitlab-org/gitlab-ce/issues/22876#note_17189231 https://gitlab.com/gitlab-org/gitlab-ce/issues/22876#note_17... let's continue the conversation there.