Integration of Graphic modeling editor & Language Server with Language Server Protocol

[alortsoc]

Hi.

I am developing a proof of concept where I try to build a graphic editor for different graphical languages (UML, BPEL, ...) where the editor is agnostic about the language used (it only knows the object palette): language knowledge is decoupled from editor using a Language Server for each language.

This is achieved using a JavaScript library with specific components for the desired graphic languages (firstly JointJS but I have moved to GoJS because of the problem described in issue https://github.com/eclipse/che/issues/3639) that has the capability of providing a JSON representation of the displayed model; this JSON representation would be processed by the Language Server (for a proof of concept, this would be good enough).

I have already implemented & deployed successfully a Language Server (with its corresponding workspace agent) for the UML representation provided by GoJS, and now I have to link the JS editor with that Language Server, and I would like to reuse as much as possible of the available code that Che already provides for this. It is specially important to be able to process Language Server responses because they will involve changes in the graphic representation provided to the user.

The use case I have in mind would be as follows:

1. When a new model is created, a sample model is created using GoJS
2. Any library event will trigger a save operation of the JSON representation of the model in the file system. As this file will have the proper file type, LanguageServer editor will trigger the change to LanguageServer to examine it.
3. LanguageServer response will somehow captured by my extension logic and will produce proper changes in the represented model.

I have verified that the LSP client is available in the che-plugin-languageserver-ide module. I foresee several ways of using that module:

1. Integrating it with my extension using its EditorProvider and somehow "shadowing" it with my graphical editor.
2. Using LSP client classes provided in package org.eclipse.che.plugin.languageserver.ide.service and implementing the rest on my own (I would prefer not doing this)
3. ... (there are many intermediate or different paths)

I would like to have some hints about which is the best way to integrate that LanguageServer Editor with my graphical editor (or if there is a better way to integrate the graphic model with a Language Server).

OS and version:
Che version: 5.2.2 OS and version: Ubuntu 16.04 (Linux kernel 4.4.0-57-generic) Docker version: 1.13.1 Che install: Binaries from Eclipse Che 5.2.2 docker containers combined with compiled assembly from the same version to integrate my graphic editor

Thank you very much for your help, Best Regards, Alberto.

[TylerJewell]

Cross-linking to another issue. https://github.com/eclipse/che/issues/3639

@alortsoc - I think these are great questions, but will probably require some of our IDE + language server experts to comment. We'll probably need to get them scheduled time to take a look and think about this a bit more. Most of them are working on finalizing some major new capabilities around intelligent commands and teams.

Can you share more about the end-product you are planning to build? If there are any commercial backers that can be shared, it may help with getting more dedicated attention sooner. We are getting 30-50 support tickets / day, so we have to juggle some of these requests day to day.

[alortsoc]

Hi Tyler,

The idea behind this proof of concept is to build a graphic editor completely agnostic about languages it is processing (UML, BPMN, ecore, ADL, Jackson notation, flow charts, ...). The piece of software implementing the editor would be the same for every possible language, and language specificities will be encapsulated in the specific object palette and in the language server that would process the diagrams, providing similar services to the ones that current language servers provide to text editors through Language Server Protocol. Current graphic tools already provide some of those services, but they have similar issues to the ones that made possible the inception of LSP, as a tight coupling between editors & languages.

This aim can be achieved in two different ways:

1. Generating a text representation of the graphic diagram and using LSP as it is to process that text representation (the path chosen for the proof of concept)
2. Augment LSP to match requirements to process graphical models (maybe to be able to define a diagram as a list of SVG objects with specific properties, this idea is in a very early stage)

The usage I envision for a tool like this, is inside the "design studio" component that many high level tools (e.g. a telecommunications operator management tool) need to allow users to build their processes. With an approach like this, it would be very easy to add new types of "process" to the tool, just adding an object palette and the language server to process that palette. I feel there is plenty of market for an idea like this, and I also think that Che is the ideal platform for such a component.

The idea of this query was to get some hints about how to use the code available in the provided LanguageServer Editor in Che to build the link between the JavaScript editor and the language server in the simplest and easiest way...

Thanks, Best Regards, Alberto.

[TylerJewell]

Alberto - that was a very helpful description. I like the idea of melding together important data processing concepts for graphical languages and the LSP. If you can create a clean enough abstraction, then the client-side tooling / visualization part becomes reusable. This would create a pretty sizable market.

Now, I am fairly unknowledgable about some of these other technologies. But have you explored an EMF port for Che and / or the xText support for the language server protocol? xText is a nice way to do DSLs that generate language servers that can be wired up. They are not graphical in nature. But I am not a modeling nor a graphics expert, so my understanding on the specifics of what applicability these technologies have is limited.

I'm going to ask support to consider your query. We are a bit busy these days as we have just signed up a large number of customers, and they as you can imagine, get at the top of the queue. But what you are working on is largely interesting as we are redoing our SDK layer to focus on using archetypes for custom assemblies to make the packaging / extension lifecycle much easier.

[gorkem]

@alortsoc Is current LSP sufficient to provide enough information for such a visualization tool. This is something we have been discussing and we are actually considering a protocol that is parallel to LSP that language servers or other services that require visual editors can implement.

[alortsoc]

@TylerJewell Yes, we are using xText to build the language server from a simplified grammar of the JSON representation generated by our JavaScript diagram library, and we are using emf4che plugin as our main reference and as guidance for our development.

@gorkem For the limited subset of use cases we want to cover, LSP to carry the JSON representation of our JS library is good enough. But I agree with you: an augmentation of LSP or even a paralell protocol as you mention would be a more consistent approach. If there were any open discussion about this subject, I really would like to be posted...

[neilmackenzie]

@alortsoc your project sounds very interesting, I think it has some similarities to an example program recently available using 'sprotty' developed by typefox (the xtext company). Maybe there are some useful ideas there for your project also since it is all available as open source.

Typefox have developed a web diagram toolkit, they have an example where a user programs in a DSL attached to a language server and the diagram renderer (written in typescript) is told about changes to the programs model via json messages provided by the Language Server. Currently the experience is one way, i.e changes to the program (and therefore the Abstract Syntax Tree of the program) are shown in the visual model, but changes to the visual model do not make updates to the program. see https://typefox.io/sprotty-a-web-based-diagramming-framework.