Re: [che-dev] language server protocol

[Tyler Jewell <tyler@xxxxxxxxxxx>]

Scott - thanks for the suggestion on partitioning language servers into OSGI services.  I'm not involved with understanding how the language servers are being implemented too much, but I have the list of people who are working on this. In fact, this week, there is a hackathon going on with 10 people from Red Hat, IBM, Codenvy and Microsoft to work on making a headless Java language server that meets the protocol's specification.  I imagine that many of the people that are working on that hackathon are not monitoring this thread.  And they should probably hear about your views on how language servers could be implemented.

Would you like me to add them to this thread, attempt to set up a slack channel, or just start a new one with your private email? I think the guys you should be speaking with are Denis (IBM), Max / Gorkem (Red Hat), Evgen (Codenvy). and Sven (TypeFox).

Since the protocol is entirely controlled by Microsoft right now - any *standards* for how language servers should be implemented architecturally outside of the specification will need to be packaged as frameworks.  Perhaps even net new Eclipse projects, for which I think Red Hat, IBM, and Codenvy are eager to do. While the protocol is standardized, we will need more projects that support the frameworks around creating language servers and consuming them to make this really stick.

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55

On Tue, Jul 12, 2016 at 11:42 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Hi Tyler,

Thanks for the info and pointers.

On 7/12/2016 10:23 AM, Tyler Jewell wrote:

Scott - that explanation was quite helpful. I guess there could be a whole world of dynamic services fronted by simple editors that have basic language server capability.  I cannot quite see all of the product scenarios that you envision, but I am getting a good flavor of it.

FWIW:   if I combine ''micro LSP services" with internet of things I can imagine some interesting new tooling and collaboration+workflow possibilities.

About the specifics of getting more details on how the various Java clients for the LSP are evolving.

1. We have two engineers now staffed to implementing language server capability into Che: Evgen + Anatoliy.  Evgen is taking the Java client and improving it along with adding richer features into our editor. Anatoliy is working on the aspects related to taking a language server and dynamically installing it into a workspace, booting it according to a recipe, and then hooking it up to the editor. 

One suggestion:   On the language server side (java impls like Eclipse), it might be wise to create/partition OSGi micro services out of the LSP api...to help with the dynamics and other things.  This would have the side effect of also working the same 'out of the box' with Eclipse, Orion, any commercial RCP apps/tooling and any OSGi server (e.g. Webpshere, Karaf, others).  

Another very nice side effect from my chair:   These services would be automatically accessible as a remote service via ECF's RSA impl...using the jsonrpc distribution provider...i.e. no new client development needed, all dynamics are handled on both clients and servers, remote service discovery supported in standard way known to Eclipse/RCP UI programmers, service interface versioning supported (multiple versions at same time), injection supported through standard frameworks (e.g. DS, Spring/Blueprint, etc), service dependencies supported, easy client development, etc.  Please ask Evgen and/Anatoliy to ask if what I'm suggesting is unclear, or if they wish to contact me directly at slewis at composent.com.

I was contemplating working on designing the service interfaces for distinct parts of LSP myself (I anticipate starting one API bundle with interface classes and the basic param and return types), but if this is going to be done perhaps it could be contributed via Che and coordinated via Evgen, Anatoliy, myself, and others.

2. All of this work is taking place in this branch. You can see the various commits, and there is separate work being done on the java library, the editor improvements, and the language server automation stuff is taking place on the server-side for us. 

https://github.com/eclipse/che/tree/language-server

3. We hope to be in a position to have a supported relase of Che that includes these capabiltiies within the quarter.

That's great, thank you.

Scott

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev