[Enhancement] Support language server protocol

[svenefftinge]

As you might know VS Code have published a so called 'language server protocol', which is a very well designed set of methods for a ubiquitous protocol. The idea is to support it in other editors as well, so there is effectively more synergy effect for implementers. We are currently working on supporting it in Eclipse Che (editor) and Eclipse Xtext (language server framework).

Please have a look at https://github.com/Microsoft/vscode-languageserver-protocol/wiki/Protocol-Implementations for a growing list of supporting projects. There are some additional works in progress that are not yet listed there.

If omnisharp would directly support it, it would work without further ado with Eclipse Che, VS Code and all other editors that will support the language server protocol in future.

[david-driscoll]

I Think it's something to consider for sure.

Would the Che framework support running an npm module? We have omnisharp-node-client that could be easily extended to implement the language services. As it handles downloading and unpacking of the binaries.

I have reservations with the current API, it covers the basic cases but it would be good for basic support. There are perhaps some advanced features that it doesn't yet support. That said I've only glanced at the spec a few times.

[svenefftinge]

Yes Che could support node easily as the workspaces run in docker images. Other editors might require users to install node locally, though. Ideally you would add the support directly in the server.

And, yes, the protocol so far only defines common IDE features that are directly supported in VS Code. E.g. something like information for outline is missing, as VS Code doesn't have that.

But I think it is a good start towards a more universally protocol between languages and editors. And we could add what is missing. I.e. you should file issues for the missing bits. :)

[TylerJewell]

Hello, @david-driscoll. I am the project lead for Eclipse Che. I appreciate @svenefftinge taking the time to initiate this discussion. We will help with any assistance and understanding where appropriate.

We understand that the Microsoft language server protocol is limiting. However, as a clean abstraction, it very well designed and makes it possible for language servers to move into many different edtiors with a lower cost of effort.

For example, within Eclipse Che, we have spent 4-5 man years engineering advanced Java language support by wrapping the JDT with a variety of custom REST syntax. What we do is gorgeous, fast, and very rich - especially in a Web browser, but that work was not portable to other languages, particularly C++ and JavaScript.

Through the advocacy of @svenefftinge and some within the Microsoft vs code team, we made a commitment to supporting the language server protocol. We expect the benefits to be 1) as more language servers are generated they can immediatley work across more editors, 2) a standard protocol will make it easier for DSLs to add intellisense capabilities, 3) we can provide frameworks for the remote access to language intelligence.

So in Che, we are implementing the following:

1. A Java language binding to the language server protocol. Che is written in Java.
2. A Che RESTful wrapper - so that any language server is accessible over REST.
3. A Che editor extension, so any language server will work automatically in the browser.
4. Support for both debugging & intellisense - though we are adding features one at a time.
5. An ability for users to add / remove new language servers into a che workspace.

Che workspaces are distributed, remote and powered by Docker containers (or other runtimes like VMs). By distributing the workspaces and providing a browser IDE, users can work on Che workspaces in any location.

This has a unique benefit - which is that since all worksapces are running similar types of operating systems, we can automate the injection / installation / configuration of language servers dynamically. And each workspace can have a different set of language servers. Language servers can be written in any language, but they do have to run on linux. When a language server is added into Che, we will deploy it into the workspace container, activate it, and then bind our Java wrapper to it. We have an agent already running inside the container that will bind to the language server. Once it is bound, all of the language services will be avaialble in the Che editor (if we have implemented them).

We will then implement an internal registry where we will detect files of a certain type and then ask users if they'd like to have a language server for that type installed into their workspace.

Workspaces are saved through snapshots and the language servers and their state are preserved.

Support for this within Che + VS code is growing. There will be an R language. We are implementing it for JSON. Microsoft has a growing list. We are also likely to make an announcement with the Eclipse Foundation on this general direction to encourage the open community to consider more aggressive adoption of this protocol.

[TylerJewell]

@david-driscoll one other item. There will be a big showing of vs code / che interop at Red Hat's devnation event in three weeks. This interop will be shown in numerous places including important sessions like keynotes. If omnisharp at a minimum could commit to providing an implementation in the future, and (even better) had a rough prototype language server working, we would include it within the various showings. Unfortunately, the timing could be argued as ridiculous :)

[david-driscoll]

I know I can bang out a prototype using the omnisharp-node-client. The catch is it then had to run node. Mainly because the infrastructure is already there.

The advantages include the client has logic for downloading the correct copy of OmniSharp version.

The biggest disadvantage is that you're then bound to the node dependency. This isn't a problem for Atom and vs code because they already run on electron.

If node is not a huge blocker I can try and get something done this weekend.

Feel free to hit me up on twitter @david_blacklite or the .net slack or OmniSharp slack. And we can figure out the details. On Sat, Jun 4, 2016 at 11:17 AM Tyler Jewell notifications@github.com wrote:

@david-driscoll https://github.com/david-driscoll one other item. There will be a big showing of vs code / che interop at Red Hat's devnation event in three weeks. This interop will be shown in numerous places including important sessions like keynotes. If omnisharp at a minimum could commit to providing an implementation in the future, and (even better) had a rough prototype language server working, we would include it within the various showings. Unfortunately, the timing could be argued as ridiculous :)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/OmniSharp/omnisharp-roslyn/issues/576#issuecomment-223761062, or mute the thread https://github.com/notifications/unsubscribe/ABNdpcZwKCM7DczmBvYrB0SbCfy2VoDAks5qIZcggaJpZM4ItdgS .

Thanks, David

[david-driscoll]

I'm going to looking at seeing if I can implement the server use the existing node client, as that should allow for a quick proof of concept.

In addition I'm going to also add this to our next Team meeting, to review what the long term goal should be.

[TylerJewell]

I have a question on the difference between the node client and the node server. The language server is a server itself so deployed within node server and then exposed as an API accessible over a binding. In Che we will have a Java binding to call the API winning in the node server. So the concept of node client - where does that fit for you?

[david-driscoll]

So the client, as it exists today is really just a wrapper / host library for OmniSharp-roslyn.

• Since we have different versions for each OS, the client manages downloading the correct version for the environment it's running against (windows, linux, linux w/o mono, mac, mac w/o mono, etc).
• It also abstracts away our protocol, so if we have other communication protocols like Native Sockets, WebSockets, etc we will have to make fewer changes to the editors plugins themselves to support that.

To make the language server work, I can just plug into that existing client code, and the only real work is creating the implementation for the vscode protocol.

[TylerJewell]

@david-driscoll Got it. We'll package up a custom workspace that includes the language server, omnisharp-rosly, and this node client. This will allow us to just plug it in and work in Che directly. You are a couple days away from having full cloud IDE support.

[david-driscoll]

https://github.com/OmniSharp/omnisharp-node-client/pull/227

Got the first draft, just coded, not tested mind you. I'll be looking at getting Che setup on my machine, only problem is it's a windows box, so we'll see how that battle goes...

[TylerJewell]

Our standard installation is vagrant for all OS - so that you don't have to mess around with operating system specifics. Also, if you are adventurous and have Docker for Windows beta - there is a nice way to run Che (very fast) as a Docker container.

Those are the quick ways to do it. If you are more adventurous, you can run Che as a server, but you need to have Java & VirtualBox previously installed for us to do our magic.

[david-driscoll]

I've got Che running on my machine (this whole thing is pretty cool to be honest!).

Are there any docs for making a custom workspace locally, so I can start to figure out how to test... :smile:

[david-driscoll]

@TylerJewell We've made some nice progress, the work is currently available @ https://github.com/OmniSharp/omnisharp-node-client/blob/7b0618c9fe9f469337505e6d600f93940914beaf/languageserver/server.ts

In the future it would be ideal to create a new OmniSharp Host, that could interface with the language server natively, but that will take a little more time to get right, but for now this solution uses the same library as omnisharp-atom, just it interfaces with the languageserver protocol.

[TylerJewell]

@david-driscoll - doing my reviews tomorrow and this weekend, along with demo preparation. Thanks for the extra effort here.

[mickaelistria]

I've been using the omnisharp-node-client for months successfully to demo the language server protocol . I think this issue can then be closed and the various glitches found in LSP support be tracked as regular issues in the right GitHub repo.

[david-driscoll]

We do want to be able to support LSP natively to allow for a much easier experience for editors to support the language service if they so choose. The node client being a great interim solution until we get there.

I'm about 80% of the way through getting the LSP models defined (and serialization tested) in C#, the next step is to actually build an interface that talks the Lsp/JsonRpc procotol.

[mickaelistria]

Ok, good to know and great if we can soon drop one layer of indirection.

[TylerJewell]

We now almost always use the Omnisharp and Java language servers in the demos of Eclipse Che. It demos incredibly well and it is mind boggling for people to see C# and Java intellisense side by side in a single product. So we appreciate the advancements you are making here.

[616b2f]

@david-driscoll any progress on native LSP support?

[mickaelistria]

See https://github.com/OmniSharp/csharp-language-server-protocol

[david-driscoll]

Indeed, I've got the library portion complete, I need to now just releasify it (myget probably) then start getting to work.

Our initial iteration is going to bring in a flag to --lsp that will kick OmniSharp into LSP mode, but behind the scenes it will most likely be our current pipeline by simply mapping between objects much like we do today.

The step after that is to sit down and see what gaps LSP has for some of the more advanced features that vscode and some other editors use, and then how best to approach them. In addition we do need to nail down our acquisition so that we have script(s) for mac / windows / linux that download the correct release for the platform it runs on.

[mickaelistria]

Hi, Is there anything we can already try on this topic? We don't need a 100% coverage of LSP operations, just a few ones to start working on integration with omnisharp-roslyn directly? Also, is there a ETA for this to come into an official OmniSharp release?

[AndrienkoAleksandr]

+1 join to @mickaelistria

[david-driscoll]

Work on this being tracked by #968

[mickaelistria]

I've tried the latest beta of omnisharp-roslyn successfully with Eclipse LSP4E (including work tracked in #968), and it's already giving a lot of good results. I suggest anyone interested in this issue to adopt to try latest beta from now on. Wouldn't it make sense to close this issue now and track ongoing progress about missing operations on #968 only?

[david-driscoll]

I believe so.