Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Eclipse GLSP
The emergence of the language server protocol enabled a significant increase in modularity and flexibility for tools and applications that provide language support for textual languages, such as programming languages. By encapsulating the language support in tool-independent language servers, their functionality can be reused across multiple tools, platforms, and applications, whether they are based on a web technology stack or on rich-client technologies, such as the Eclipse IDE, Eclipse Theia, or other platforms.
Today, graphical modeling tools, such as diagram editors for flowcharts or UML class diagrams, are typically coupled to their tool platform, as they require a lot of infrastructure that is only available in platform-specific modeling frameworks, such as the Graphical Modeling Framework (GMF). This makes it difficult to transfer or share graphical modeling tools among different platforms. Even the tool-independent logic, for instance, the definitions which elements can be created or which editing operations are allowed in a certain context, can hardly be reused across different tool platforms. However, graphical modeling tools would also significantly benefit from a modular architecture, similar to the one of language servers for textual languages, because such an architecture would mitigate the current constraints and limited flexibility regarding their tool platform, user interface toolkits, and deployability. With such an architecture, large parts of the implementation of a graphical language support could be shared across multiple platforms and toolkits.
This project is strongly related to Eclipse Sprotty, as it heavily builds upon Sprotty for implementing a web-based graphical language client and reuses its existing client-server protocol for transferring graph models that represent diagrams. The Eclipse GLSP puts on top of Eclipse Sprotty: (i) a standalone server framework for implementing specific diagram servers, (ii) enhancements of the client-server protocol to allow the server to communicate available node and edge types, allowed edit operations, etc., as well as (iii) graphical language client implementations for different platforms. The graphical language client implementation for web-based platforms, such as Eclipse Theia, builds on Eclipse Sprotty directly and is, due to its technical proximity, also intended to be directly contributed to the Sprotty project.
An initial prototype as well as the principle idea of the graphical language server framework was presented at the EclipseCon Europe 2018.
The scope of the Eclipse GLSP comprises...
- A generic server framework for building language-specific graphical language servers
- A protocol for communicating graphical language definitions (e.g. which edit operations are allowed in a certain context), as well as for transferring the application of edit operations
- A generic client framework for different platforms in order to allow building specific graphical language clients that can communicate with graphical language servers
Out of scope are…
- Diagramming frameworks, such as Eclipse Sprotty or GEF and GMF. Those shall be reused in order to build graphical language clients for different platforms.
- Tools to define or generate diagram editors, such as GMF Tooling or Sirius.
The GLSP provides extensible components to enable the development of diagram editors including edit functionality in (distributed) web-applications via a client-server protocol. By applying the architectural pattern of the language server protocol (LSP) to graphical languages and diagram modeling tools, it aims to achieve the same modularity and flexibility for diagram editors that has been enabled by the LSP for textual languages.
Textual languages, as supported by the LSP, significantly differ from graphical languages due to their graph-based structure, due to their way of being visualized in an editor, as well as due to the nature of editing commands users can perform. Thus, it is impractical to directly reuse the language server protocol and language server or client frameworks. Instead, dedicated protocols and frameworks tailored to the specific requirements of graphical languages and diagram editors are required.
The main goal of GLSP is to encapsulate as much knowledge as possible about the graphical language on the server in the sense that available node and edge types, available operations, or validation is performed on the server, while the client-side editor is only responsible for rendering the diagram, providing the editing tools for the edit operations defined by the server, as well as visual feedback while editing. The actual manipulation of the underlying graph model is eventually delegated to the server, which after performing the manipulation, just sends an update to the client, which will then update the diagram rendering.
Therefore, the Graphical Language Server Platform aims at providing the following components:
- Java-based server framework for building specific standalone diagram servers
- Client-server protocol allowing the server to communicate available node and edge types, allowed editing operations, as well as for the client to invoke editing operations that are to be performed on the server
- Frameworks for building diagram clients for different platforms
Eclipse has a long history of providing a home to all sorts of popular modeling technologies, including those for graphical modeling. In particular, the proposed project will heavily build on Eclipse Sprotty and is loosely related to other modeling technologies, such as GEF for rich-client based graphical language clients or EMF for managing models on the server.
- Support for all typical editing functionality, such as undo & redo, property views, layout commands, copy & paste, etc.
- Stabilization and improvements of an API for server and client customization
- Simplification of authoring language-specific diagram servers
- Client implementations based on other base technologies, such as GEF
The initial prototypical implementations will be contributed shortly after the proposal is accepted. After that we initiate regular milestone builds.
- Jan Köhnlein (TypeFox)
- Miro Spönemann (TypeFox)
- Pierre-Charles David (Obeo)
- Benoit Combemale (Inria)
Initial prototypical implementation of (i) a standalone server framework for implementing specific diagram servers, (ii) enhancements of the client-server protocol to allow the server to communicate available node and edge types, allowed edit operations, etc., as well as (iii) graphical language client implementation based on Sprotty, unless this component will be contributed to the Eclipse Sprotty project.
- Log in to post comments
- Log in to post comments