Yes! Consider some random feature of a language server, such as syntax highlighting, or displaying diagnostics, or file outline. There’s two ways the editor (which displays stuff to the user) can learn the necessary information from the server (which has the brains to actually compute the stuff).
In the pull model, the clients asks the server to send the info over when it needs it (a new file is open) or when it thinks it needs a refresh (ie, when the used typed something new).
In the push model, the server pushes the info anytime it detects that the info might have changed. So, the client pushes text edits to the server, and, sometime later, the server asynchronously “responds” with updated information.
Historically, in LSP everything except for diagnostics used pull model, while the diagnostics were push. Now, lsp implemented pull for diagnostics as well, and soft-deprecated the push model.
My personal stance here (which I am fairly confident in, but don’t have time to argue in detail right now), that both models are wrong. Both are very RPC-flavored, X asks Y to do Z, and RPC is the wrong paradigm here. What actually happens here is state synchronization – at any given point in time, there’s some specific state of highlights or diagnostic, this state changes over time, and we want the client & the server to maintain a shared view of the state. The right model here is subscription:
the client notifies the server which bits of data it is interested in (eg, I want syntax highlighting for files foo.rs and bar.rs). These notifications give raise to the persistent state of subscriptions the client currently has
the server, knowing the subscriptions, sends the relevant data to the client everytime it changes.
This subscription model is how dart analyzer protocol works and (I think) roughly how JetBrain’s rider protocol works.
thanks for the detailed explanation 👍
Your view on state-sync is quite interesting.
If you already wrote about how pull/push models are the wrong approach, I would be interested in a longer argument about that.
Sadly there’s no vscode tag, nor a generic editor one.
Anyone knows what that refers to ?
Yes! Consider some random feature of a language server, such as syntax highlighting, or displaying diagnostics, or file outline. There’s two ways the editor (which displays stuff to the user) can learn the necessary information from the server (which has the brains to actually compute the stuff).
In the pull model, the clients asks the server to send the info over when it needs it (a new file is open) or when it thinks it needs a refresh (ie, when the used typed something new).
In the push model, the server pushes the info anytime it detects that the info might have changed. So, the client pushes text edits to the server, and, sometime later, the server asynchronously “responds” with updated information.
Historically, in LSP everything except for diagnostics used pull model, while the diagnostics were push. Now, lsp implemented pull for diagnostics as well, and soft-deprecated the push model.
My personal stance here (which I am fairly confident in, but don’t have time to argue in detail right now), that both models are wrong. Both are very RPC-flavored, X asks Y to do Z, and RPC is the wrong paradigm here. What actually happens here is state synchronization – at any given point in time, there’s some specific state of highlights or diagnostic, this state changes over time, and we want the client & the server to maintain a shared view of the state. The right model here is subscription:
foo.rsandbar.rs). These notifications give raise to the persistent state of subscriptions the client currently hasThis subscription model is how dart analyzer protocol works and (I think) roughly how JetBrain’s rider protocol works.
thanks for the detailed explanation 👍 Your view on state-sync is quite interesting. If you already wrote about how pull/push models are the wrong approach, I would be interested in a longer argument about that.