Communication between new GUI and Language Server

[hubertp]

Could we get a bit of hindsight into how the new GUI changes the interaction with an existing Language Server implementation?
So far the teams' assumption was that nothing changes in terms of protocol or clients.

But that does not seem to be entirely the case, as indicated by for example #7898 (comment).
Language Server was in theory designed to support multiple clients. At some point it didn't make much sense to support something that wasn't used in practice. So our testing might be lacking in that area and that ticket is one indication. And requirement to support multiple clients per LS will like lead to some other problems.

So could we get a rough draft on how the new GUI is likely to communicate with LS to stress-test where problems might occur?

[farmaazon]

The GUI2 is implemented with multiple clients in mind, using Yjs library, which gives us much of CRTD for relatively free (it also provides some mechanism for undo-redo).

Of course, while "having in mind" we still test and focus on a single client scenario. But we also have a "Yjs server" service which also is responsible for synchronizing Yjs documents with language server. So this server connects with language server to load and synchronize files, but other clients may also connect directly to LS to create execution context, attach visualizations etc. So, even in a single electron launched, there will be still two clients from LS perspective.

There is an alternative approach, where we do not have a specific server, but one of the clients is responsible for synchronizing files with LS. That's require a bit more work, but in the single client scenario it should not make any difference to LS when compared to the old GUI

Also calling in @Frizi who developed our current architecture. You may add something what I didn't.

[hubertp]

Thanks!