Doubts about centralized servers

[menduz]

I have some questions about this protocol and how is meant to be implementated.

1. Must it run locally along the IDE?
2. Should the LS accept different IDE sessions on a single instance?
3. I saw that vscode uses IPC for communication, is there a hard requirement/specification for the protocol or can we use WebSockets e.x.?
4. If yes to 1. and it can run remotely, does the protocol provide any security mechanism?

[TylerJewell]

Hi @menduz:

1. The language server does not need to run alongside the IDE. In Eclipse Che's implementation, the language server runs in a remote workspace and gets a RESTful JSON wrapper created around it. The wrapper is running in a JVM and the language server runs natively as a process. The browser IDE then communicates over web sockets to the RESTful wrapper which in turn invokes language servers through standard in/out.
2. I don't think the specification makes this explicit right now and many existing language servers only accept one session / instance.
3. You can use web sockets. Eclipse Che's RESTful implementation wrapper is open source if you want to reuse that, for example.
4. There is no security mechanism defined in the protocol. Security and permissions are currently delegated to the IDEs. In Che, for example, each workspace has its own sets of permissions with different language servers installed. So security is handled at an abstract level vs. a model where a single language server is providing intellisense to many users simultaneously.

There are debates in the open market as to which is a better model. The Che viewpoint is that it would be difficult to have a clean abstraction where a single language server services many clients at the same time. While you get multi-tenanted intellisense, those same clients are going to need other tools like compilers, package managers, and debuggers which are not governed by the same protocol and distinct per workspace - so seems that just having multi-tenanted language server without the rest will create unforeseen challenges. This is our perspective and not a universally shared one.

[menduz]

Thanks @TylerJewell !

1. In a certain way, it runs locally along the Che's server then?
2. There is some spec around that RESTful implementation, at Mulesoft we are evaluating make some LS and it would be nice to have it running on Che?

[TylerJewell]

Che's server and each workspace created by Che are in different containers. So a user with 2 workspaces has two isolated runtimes. We install the language server into the workspace runtime where our RESTful adapter is applied.

The RESTful interfaces that we have are published on github.com/eclipse/che, but you don't really need to understand them. We will accept any local language server operating against this JSON local protocol. We then have a common editor plugin that communicates between the browser and our RESTful adapter. So all you have to do is provide a language server according to this spec, add installation details on how the server can be launched.

We'll provide a public registry where language servers can be added for discovery by various IDEs.

[menduz]

Thank you @TylerJewell

[jared2501]

Hey @TylerJewell any chance you could provide a link to the adapter code that manages the language-servers in Che? Had a poke around the Che github and the closest I could find is this which doesn't appear to be in master.

[jared2501]

Ahh never mind, found it on the "language-server" branch.. I'm an idiot

[felixfbecker]

@TylerJewell I gotta ask - how can you proxy an RPC protocol (remote procedure call) through HTTP and call it RESTful (representational state transfer)? RPC and REST are total opposites

[TylerJewell]

We have a RESTful wrapper around the JSON RPC protocol. It's not very granular to reflect the detail that is within the specification here, but it is the structure of how Che editors interact with language servers. I should have been more explicit with my language. And we should produce a nice architecture graphic that reflects this.

[felixfbecker]

Really curious how that looks like if it is really RESTful. What level is that wrapper on the Richardson Maturity Model?

[TylerJewell]

The entirety of communications between the IDE and the workspace is RESTful for initiating actions. There are selective points where streaming content is then transitioned over to a websocket channel. In the case of the language server protocol, there are certain major actions which are RESTful, and some that are not - I don't think our granularity of the RESTful interface reflects the RPC protocol that closely. I am not familiar with the RMM, it is a concept that is new -- if it was intriguing for you to know, i can ask some engineers to look at it and compare against what we did.

[felixfbecker]

You mentioned it is open source, do you have a link? RMM is basically just

[TylerJewell]

Yeah, sure - the filter on all of the language server issues committed into Che is here. https://github.com/eclipse/che/pulls?q=is%3Apr+Language+Server+is%3Aclosed. I think you want the commits associated with PR #2452. eclipse-che/che#2452. I haven't poured through enough of the code to know the granularity for it, but given that the implementation was done in 4 months, I suspect it is coarse grained.

[dbaeumer]

@menduz regarding 2.): currently the protocol assumes that there is a 1:1 mapping between [tool instance, workspace] and language server. Major reason being that the protocol as no spec for document sharing between tools. Consider for example two different editors opening the same workspace on a local machine and sharing the same language server. If we want to support the protocol must spec how modification on the same text document in the two tools should be handled.

[menduz]

@dbaeumer Thanks!

[dbaeumer]

To keep the number of issues in our inbox at a manageable level, we’re closing issues that have been on the backlog for a long time but haven’t gained traction. I think the current state of the protocol and intended uses cases have been explained. If we think we should change this then we need concrete proposal we should work on. Thank you for your time and understanding.

If you disagree and feel that this issue is crucial: we’re happy to listen and to reconsider.