Towards a language server protocol infrastructure for graphical modeling
1 like367 views
The development of modern IDEs is still a challenging and time-consuming task, which requires implementing the support for language-specific features such as syntax highlighting or validation. When the IDE targets a graphical language, its development becomes even more complex due to the rendering and manipulation of the graphical notation symbols. To simplify the development of IDEs, the Language Server Protocol (LSP) proposes a decoupled approach based on language-agnostic clients and language-specific servers. LSP clients communicate changes to LSP servers, which validate and store language instances. However, LSP only addresses textual languages (i.e., character as atomic unit) and neglects the support for graphical ones (i.e., nodes/edges as atomic units). In this paper, we present our vision to decouple graphical language IDEs discussing the alternatives for integrating LSP's ideas in their development. Moreover, we propose a novel LSP infrastructure to simplify the development of new graphical modeling tools, in which Web technologies may be used for editor front-ends while leveraging existing modeling frameworks to build language servers.
![Background: Language Server Protocol 3.0
Main issue: designed for textual
programming languages
● Text ranges are a basic type
=> making easy for clients to
connect to different LS in a seamless
way, because the protocol is
completely language-agnostic
NotificationMessage {
method : "textDocument/didChange",
params : {
textDocument : {
version : 2
},
contentChanges : [
{ range : {
start : {
line : 21,
character : 6
},
end : {
line : 33,
character : 6
}
}
text : ""
}]}}](https://image.slidesharecdn.com/towardsalanguageserverprotocolinfrastructureforgraphicalmodeling3-181019111850/85/Towards-a-language-server-protocol-infrastructure-for-graphical-modeling-9-320.jpg)
![Mapping GME operations into LSP
NotificationMessage {
method :
"textDocument/didChange",
params : {
textDocument : {
version : 2
},
contentChanges : [
{ range : {
start : {
line : 21,
character : 6
},
end : {
line : 33,
character : 6
}
}
text : ""
}]}}
RequestMessage {
jsonrpc : "2.0",
id : "0001",
method: "workspace/ApplyEdit",
params : {
edit : {
documentChanges : [
{
textDocument : { version: 2 },
edits : [
{ range : {
start : {
line : 03,
character : 00 },
end : {
line : 35,
character : 00 }
},
newtext: ""
}]]}}}
ResponseMessage{
jsonrpc : "2.0",
id : "0001",
result : { applied : true }
}
Client => Server Server => Client Client => Server](https://image.slidesharecdn.com/towardsalanguageserverprotocolinfrastructureforgraphicalmodeling3-181019111850/85/Towards-a-language-server-protocol-infrastructure-for-graphical-modeling-24-320.jpg)
![Mapping GME operations into LSP
01 {
02 "elements" : []
03 }
D’oh!](https://image.slidesharecdn.com/towardsalanguageserverprotocolinfrastructureforgraphicalmodeling3-181019111850/85/Towards-a-language-server-protocol-infrastructure-for-graphical-modeling-25-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Towards a language server protocol infrastructure for graphical modeling (20)
Ad
Recently uploaded (20)
![PRTG Network Monitor Crack Latest Version & Serial Key 2025 [100% Working]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250504182022-6534c7c0-thumbnail.jpg?width=560&fit=bounds)
Ad
Towards a language server protocol infrastructure for graphical modeling
- 1. Towards a Language Server Protocol Infrastructure for Graphical Modeling Roberto Rodriguez-Echeverria, Javier L. Cánovas, Manuel Wimmer and Jordi Cabot
- 2. Context Complex addition of new languages Complex migration to Web/Mobile The development of full-fledge graphical modeling editors is a challenging and complex task.
- 3. Context User experience Language support Complex addition of new languages Complex migration to Web/Mobile The development of full-fledge graphical modeling editors is a challenging and complex task. Two main concerns to consider separately (?)
- 4. LSP Language Server Protocol IDE Language servers MxN problem (3x9) to M+N problem (3+9) https://langserver.org/
- 5. Problem No scientific assessment or tool provider position on: LSP provides enough expressiveness for graphical manipulations LSP should be extended to support specific features of graphical edition It would be best to ignore LSP in graphical modeling
- 6. Background: graphical modeling editors Its development is more complex than textual modeling editors development: - Atomic unit: char vs node-edge - Processing: from top-left to bottom-right vs node relationships - Serialization: raw text vs specific format (e.g. XMI)
- 7. Background: graphical modeling editors Editor & Views Semantic Operations Diagrammatic Operations Auxiliary Operations Graphical modeling editor Selection (type) Hover (completion) Completion (pop-up) CRUD (elements) CRUD (properties) Auto-layout Validation ... Selection (free) Hover (information) Zoom Align Filter Group Hide Storage Initialization Shutdown Main operations in model editing categorized
- 8. Background: Language Server Protocol 3.0 https://microsoft.github.io/language-server-protocol/overview
- 9. Background: Language Server Protocol 3.0 Main issue: designed for textual programming languages ● Text ranges are a basic type => making easy for clients to connect to different LS in a seamless way, because the protocol is completely language-agnostic NotificationMessage { method : "textDocument/didChange", params : { textDocument : { version : 2 }, contentChanges : [ { range : { start : { line : 21, character : 6 }, end : { line : 33, character : 6 } } text : "" }]}}
- 10. Challenges Reducing development and maintenance costs for graphical modeling editors Using the Web as the platform for modeling editors deployment while reusing modeling frameworks for language servers Managing different languages developed with different modeling platforms from a single editor Providing a single user experience of modeling editors so users can easily deal with different languages
- 11. Vision: decoupled architecture Editor & Views Semantic Operations Diagramatic Operations Auxiliary Operations Graphical modeling editor 11 Modeling framework (platform specific)
- 12. Vision: decoupled architecture Editor & Views Diagramatic Operations Graphical modeling client Semantic Operations Diagramatic Operations Auxiliary Operations Graphical language serverPartial decoupling Reduced client-server bandwidth Specialized UX Simpler language server Hybrid representations Complex client/UX plat. Poor extensibility (other languages) - + Semantic Operations 12 Modeling framework (platform specific) UX platform (modeling framework ported)
- 13. Vision: decoupled architecture Editor & Views Diagramatic Operations Graphical modeling client Semantic Operations Diagramatic Operations Auxiliary Operations Graphical language serverFull decoupling Reusing MFs Platform-agnostic editor Multi-language editor Complex server High bandwidth consumption - + 13 Modeling framework (platform specific) UX platform
- 14. Vision: communication protocol Using LSP Standard Reuse LSP tools Future features For textual langs. No hybrid representations Extending LSP Standard Reuse LSP tools Future features Hybrid representations Concrete syntax support at client Textual rep. req. New protocol Element ids Optimized for gme operations Standard (?) LSP overlapping LSP compatibility - + + - + -
- 15. Vision: communication protocol Although the pros of defining a new protocol or extending LSP may be substantial, we argue that using LSP itself plus a textual representation is expressive enough for graphical languages, and most of its drawbacks may be properly addressed by providing the needed LSP infrastructure. LSP provides enough expressiveness for graphical manipulations
- 16. LSP infrastructure for graphical modeling
- 17. Intermediate Representation Format A JSON-based format: ● abstract, ● concrete ● and diagrammatic properties Design driven for two main forces: ● encompassing abstract and concrete syntaxes in a single resource ● provision of the necessary information to the client “Node-edge” representation
- 19. Mapping GME operations into LSP Identification of operations Reviewed three MDE graphical editing tools: ● Papyrus, ● Sirius ● and GMF Study of operations Defined a comprehensive set of use cases to illustrate how we can map user operations into LSP messages by leveraging on IRF 1 2
- 20. Mapping GME operations into LSP Identification of operations Reviewed three MDE graphical editing tools: ● Papyrus, ● Sirius ● and GMF 1
- 21. Mapping GME operations into LSP Study of operations Defined a comprehensive set of use cases to illustrate how we can map user operations into LSP messages by leveraging on IRF 2https://som-research.github.io/lsp4gml/cases.html
- 22. Mapping GME operations into LSP P1 C1 01 { 02 "elements" : [ 03 "node" : { 04 "id" : "c1", 05 "type" : "class", 06 "abstract" : { 07 name : "C1", 08 qualifiedName : "P1::C1", 09 ... 10 }, 11 "concrete" : { 12 width : 20, 13 Height : 20 14 }, 15 "diagram" : { 16 x : 15, 17 y : 15 18 }, 19 ... 20 }, 21 "node" : { 22 "id" : "p1", 23 "type" : "package", 24 "abstract" : { 25 name : "P1", ... } 26 "concrete" : { 27 width : 100, 28 Height : 100 }, 29 "diagram" : { 30 x : 0, 31 y : 0 }, 32 ... 33 }, 34 "edge" : { 35 "id" : "e1", 36 "type" : "ownedClasses", 37 "group" : "true", 38 "origin" : "p1", 39 "target" : "c1", 40 "abstract" : { ... Maybe, I don’t need it
- 23. Mapping GME operations into LSP 01 { 02 "elements" : [ 03 "node" : { 04 "id" : "c1", 05 "type" : "class", 06 "abstract" : { 07 name : "C1", 08 qualifiedName : "P1::C1", 09 ... 10 }, 11 "concrete" : { 12 width : 20, 13 Height : 20 14 }, 15 "diagram" : { 16 x : 15, 17 y : 15 18 }, 19 ... 20 }, 21 "node" : { 22 "id" : "p1", 23 "type" : "package", 24 "abstract" : { 25 name : "P1", ... } 26 "concrete" : { 27 width : 100, 28 Height : 100 }, 29 "diagram" : { 30 x : 0, 31 y : 0 }, 32 ... 33 }, 34 "edge" : { 35 "id" : "e1", 36 "type" : "ownedClasses", 37 "group" : "true", 38 "origin" : "p1", 39 "target" : "c1", 40 "abstract" : { ... P1 C1 Let’s delete P1
- 24. Mapping GME operations into LSP NotificationMessage { method : "textDocument/didChange", params : { textDocument : { version : 2 }, contentChanges : [ { range : { start : { line : 21, character : 6 }, end : { line : 33, character : 6 } } text : "" }]}} RequestMessage { jsonrpc : "2.0", id : "0001", method: "workspace/ApplyEdit", params : { edit : { documentChanges : [ { textDocument : { version: 2 }, edits : [ { range : { start : { line : 03, character : 00 }, end : { line : 35, character : 00 } }, newtext: "" }]]}}} ResponseMessage{ jsonrpc : "2.0", id : "0001", result : { applied : true } } Client => Server Server => Client Client => Server
- 25. Mapping GME operations into LSP 01 { 02 "elements" : [] 03 } D’oh!
- 26. Proof of Concept MDETools 2018 “An LSP infrastructure to build EMF language servers for Web-deployable model editors” https://github.com/SOM-Research/lsp4gml
- 27. Conclusions and Future Work We discussed different alternatives of clients, servers and the LSP usages for decoupling graphical language editors. We described an approach relying on standard LSP and a text-based model representation shared between clients and servers. Roadmap: ● Automatic generation of graphical language servers ○ To what extent is feasible? ● Performance assessment ○ bandwidth optimization and server-side enhancements.
- 28. Decoupling GME dev into a client-server architecture using a convenient protocol is a key approach. Let’s use an open common protocol to share our graphical language servers Final Remark
- 29. Thank you
- 30. Towards a Language Server Protocol Infrastructure for Graphical Modeling Roberto Rodriguez-Echeverria, Javier L. Cánovas, Manuel Wimmer and Jordi Cabot