This PR simplifies the server's initialization process.
Initialization starts when the client sends an initialize request, the server responds, and finally the client sends initialized to acknowledge everything is good to go.
But the initialization of our server is split between these two functions.
We pass in some of the config during initialize, then in initialized we request the remaining configuration from the client.
This split approach means:
We need 2 functions operating in different ways instead of a single function.
The server spends some time in a partially initialized state, which the Rust type system has to cope with.
It violates the spirit of initialized. By the time initialized is received, everything should already be fully initialized. But our server isn't. It's still initializing.
This PR changes this so all the initialization is done up front, in one-shot.
The client now sends all it's configuration in the first initialize request, so the server can fully initialize itself then.
We still receive the initialized request, because the server waits for it before sending diagnostics back.
Because it's unsound to send arbitrary data to the client before everyone is initialized and ready for it.
I remember talking about the nuance around these functions, and there's a comment that alludes that "the client might not be ready to send it's config". Reading the spec sounds like this PR is the right way to go though, and I've tested it on my machine to no issues. If anyone has any insight (or testing capabilities to offer!), I welcome it.
But currently, all our configuration just comes right out of settings.json, which is known and loaded by the time the extension starts. It has to be, because that's how we check if the server is enabled at all.
This PR simplifies the server's initialization process.
Initialization starts when the client sends an
initializerequest, the server responds, and finally the client sendsinitializedto acknowledge everything is good to go.But the initialization of our server is split between these two functions. We pass in some of the config during
initialize, then ininitializedwe request the remaining configuration from the client.This split approach means:
initialized. By the timeinitializedis received, everything should already be fully initialized. But our server isn't. It's still initializing.This PR changes this so all the initialization is done up front, in one-shot. The client now sends all it's configuration in the first
initializerequest, so the server can fully initialize itself then.We still receive the
initializedrequest, because the server waits for it before sending diagnostics back. Because it's unsound to send arbitrary data to the client before everyone is initialized and ready for it.I remember talking about the nuance around these functions, and there's a comment that alludes that "the client might not be ready to send it's config". Reading the spec sounds like this PR is the right way to go though, and I've tested it on my machine to no issues. If anyone has any insight (or testing capabilities to offer!), I welcome it.
But currently, all our configuration just comes right out of
settings.json, which is known and loaded by the time the extension starts. It has to be, because that's how we check if the server is enabled at all.