Provide a dependency graph via an existing language server

[glsp-bot]

Hi!

I try to understand if GLSP would be a good approach to visualize a dependency graph in my language server. It's a bit hard to understand how the different components/repositories relate to each other and which are superseded by other things. (I saw the related post https://spectrum.chat/glsp/general/how-do-all-the-related-projects-relate-to-one-another-and-with-glsp~1994d9b7-168d-478d-b0b4-ff6565945169.)

• If I understand correctly, there is currently only a server implementation of glsp in Java?

• Where can I find the glsp specification, the equivalent of https://microsoft.github.io/language-server-protocol/specification? I found this https://github.com/ObeoNetwork/GraphicalServerProtocol/blob/master/specification.md, but it wasn't touched for quite some time.

Let me describe what I want to do:
I am currently playing with a language server for CMake. Since CMake itself is written in C++ (and C++ is my primary language), I decided to implement the language server protocol in C++. It's very incomplete and more an experiment.
Now I wanted to add the possibility to visualize dependencies between (CMake) targets. I see 2 possible use-cases: a) just visualize the dependency graph (server->client) b) allow changing the graph (server <-> client).

• use-case a) It seems overkill to implement GLSP for such a simple visualization. Maybe the better way is to just communicate the dependency graph to the client via a new LSP message and let the client (probably with sprotty) do the layout and visualization. (My understanding is, in glsp the server would define the layout of the diagram.) Would you agree?

• use-case b) Assuming I would want to go one step further and allow the user to manipulate dependencies in the sprotty diagram. This would be a use-case where GLSP would be very valuable, right? Would it make sense to implement a GLSP server in C++? Would it be much more work than implementing LSP?

Cheers,
Hannes

original thread by Hannes Vogt

[planger]

Hi Hannes,

your understanding of the involved components is generally correct.

There is a server framework for GLSP which is currently only available for Java. We are a bit behind in terms of documenting the protocol itself. We have a rather outdated documentation of the protocol but we plan to update it hopefully soon. To get an up-to-date picture of the protocol, it is best to check out the classes that represent the action messages sent between the client and the server here: https://github.com/eclipse-glsp/glsp-server/tree/master/plugins/org.eclipse.glsp.api/src/org/eclipse/glsp/api/action/kind

If you use the Java server framework, you don't need to understand all details of the protocol though as it encapsulates much of it and all you need to do is to register handlers for certain actions sent be the client, such as create node, delete, etc. and implement the factory of the graph model (in your case obtain the relevant information from your language server and create a graph model representing the dependencies from it).

Looking at your use-case, I would agree: if you would like to 'just' visualize certain aspects from your language server, I'd recommend to just go with Sprotty. Note that Sprotty also only provides a Java-based server though. So you'd have to build a similar server from scratch too if you want to stick with C++.
In this scenario, you would write a server (based on that framework or from scratch) that connects to your language server (e.g. using custom messages) and translate the information obtained from the language server into a so-called SGraph that is then sent to the client, which renders it using the Sprotty client.

If you would like to support full editing too, GLSP is probably the better choice as it already provides you with the editing tools on the client and corresponding protocol messages. It would start out very similar as with Sprotty (ie creating a server that connects to your language server and translates that into a graph model that is sent to the client, which renders it). But then in addition, you would implement action handlers that handle modifications. The common pattern is that these handlers would directly manipulate the 'model' via your language server and then re-create the graph model to be sent as a model update to the client. This way you have a 'reactive circle' (create graph from language server -> render it -> translate change actions to modifications in the language server -> create graph from language server -> render it -> ...).

Would it make sense to implement a GLSP server in C++?

It would be possible for sure, but it would be way more work than building the GLSP server on top of the Java-based GLSP server framework. Since your LSP and GLSP can run in separate processes and communicate via socket there doesn't seem to be a drawback of sticking with the Java-based server framework, so I'd rather go with the using the Java-based framework.

Would it be much more work than implementing LSP?

Of course it depends on the respective languages, but in general I would say that implementing a GLSP server is less work than implementing a full-blown language server (LSP). Implementing a GLSP solution is basically defining the graph model and how it is created ('factory'), implementing the rendering of that graph model on the client (this is infact the same for the plain Sprotty-based or GLSP-based solution), and then implementing and registering the action handlers on the GLSP server to perform the modifications via your LSP.

I hope this helps! Let us know if you have more questions!

Best wishes,
Philip

[glsp-bot]

[Hannes Vogt]

Thanks Philip, that clarified a lot of things. Cheers, Hannes