There is currently a large hype surrounding the language server protocol (LSP) which provides a very flexible and well-proven architecture for implementing textual language support. Wouldn’t it be cool to use a similar protocol and architecture for graphical modeling languages, too? Following in the footsteps of LSP, is it possible to allow a “generic diagram editor” talk to a graphical language server, retrieving information such as how nodes are rendered, how they can be connected, or which elements can be created from a palette? Join us at this talk to find out what is going on around this topic!
A protocol-based implementation for graphical editors in the web sounds like an obvious follow-up of the LSP. However, diagrams are not the same as source code, they have fundamentally different editing features such as complex combinations of shapes that can be connected, resized, or nested with drag and drop. To find out what’s possible and what makes sense, we have started the implementation of a proof of concept for such a protocol in collaboration with interested parties. The obvious starting point for this was the open source framework Sprotty, a new graphical framework in the Eclipse ecosystem. It already contains a protocol (an extension to LSP) to synchronize graphs from a server to the client. Therefore, we started to extend Sprotty by new protocol parts, such as editing, a palette concept, and possible node references.
This talk discusses the topic of a possible Graphical Language Server Protocol (GLSP) based on Sprotty along with technical demonstrations of a proof of concept. We will put a special emphasis on what seems possible and what does not and whether or not this can be moved towards a graphical language server protocol based on Sprotty.