Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] language server protocol

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. 

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


Back to the top