-
Hello, With this discussion, I just want to make sure that my current understanding of how the different GLSP components work together is accurate. Suppose you have a GLSP project with a Theia client. If you wanted to use the diagram editor remotely from somewhere, you would simply connect to Theia itself, which is running in the cloud together with the GLSP server. The GLSP server and its client(s) are not actually supposed to be separated and run on different machines. The purpose of the "server" is simply to have a consistent backend across different clients that run on the same machine. I initially thought that you were supposed to connect remotely to the GLSP server, but that does not seem to be the case. This also means that you would not be able to connect to a GLSP server from VSCode running on a different machine for example. This project template from the EMF.cloud repository is pretty much the same as the corresponding project template in the GLSP repository, but it has an additional modelserver next to the GLSP server. What is this for? Thanks in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi, yes, you are correct! The term server -- as used in GLSP and LSP -- may be a bit misleading. It is a "service" that runs in a separate process, but is usually not a server in the sense of a webserver (could be though, but typically is not). In a typical Theia deployment, the GLSP server processes, as well as the LSP server processes, run on the same machine or in the same docker container as the Theia backend and the Theia backend connects via plain sockets for the inter-process communication. The frontend (browser or electron-browser) has one web socket connection to the Theia backend, which in turn forwards all messages for the GLSP/LSP server via a socket connection on to the GLSP/LSP server and vice versa. As GLSP also supports standalone use cases, you can also directly connect via websocket from the frontend (browser) to the GLSP server -- without a backend in the middle. But in the Theia scenario, this is typically disadvantageous, as you typically only want to have one websocket connection between the frontend and the backend, as this is easier to manage in cloud deployments.
Well, yes and no. You could also directly connect from the webview that shows the GLSP diagram via websocket to any remote GLSP server, but by default this isn't the case as it is channeled through the VS Code backend. |
Beta Was this translation helpful? Give feedback.
Hi,
yes, you are correct! The term server -- as used in GLSP and LSP -- may be a bit misleading. It is a "service" that runs in a separate process, but is usually not a server in the sense of a webserver (could be though, but typically is not).
In a typical Theia deployment, the GLSP server processes, as well as the LSP server processes, run on the same machine or in the same docker container as the Theia backend and the Theia backend connects via plain sockets for the inter-process communication. The frontend (browser or electron-browser) has one web socket connection to the Theia backend, which in turn forwards all messages for the GLSP/LSP server via a socket connection on to the GLSP/…