Spec should discourage abuse of initializationOptions and didChangeConfiguration

[mickaelistria]

I'm working on having Eclipse IDE adopting some language servers.
I see a possible bad trend for Language Servers to heavily rely on initializationOptions and didChangeConfigurations to enable/disable features. The issue with those is that they are unspecified placeholders and that whatever usage is made of it requires all clients to write code specific to this language server to support those options.
The main example I have in mind right now is RLS that, by abusing those settings is progressively, and most likely without really willing it, breaking rich compatibility with other IDEs: rust-lang/rls#1047
Abuse of those properties should be deprecated in the spec, with some disclaimer explaining how relying on those make the LS integration less likely to be trivially portable from an editor to another.

[rcjsuen]

Interesting. I use workspace/didChangeConfiguration as that's what was there but did not consider this case.

At what point would you consider the use of this "abuse" though?

[mickaelistria]

As an adopter of LS I don't develop, I consider any usage is abuse, as long as it requires to create a specific UI or workflow to interact with it in the client ;) But I hope this discussion can lead to a more flexible definition.

[LaurentTreguier]

As I see it, a server initialized without initializationOptions should just work in any editor. If the editor allows servers to be started by custom extensions with possible deeper integration (like VSCode or Atom for example), then initializationOptions can be used to enable specific features that can't be used in other editors.

[mickaelistria]

@LaurentTreguier: so your proposal is that the settings should be limited to only client-specific configuration? I think it'd be fair.

[LaurentTreguier]

This is how I understood it. The spec describes it as User provided initialization options, which can be misleading; it makes it sound like the user should change it themselves when it should be up to a specific client to do this.

[dbaeumer]

IMO the spec should encourage all server providers to spec the following to things:

• the initialization options it supports. I agree with @LaurentTreguier that a server should work with an empty literal as well and simply assume a set of defaults.
• which workspace/configuration request it sends.

Having a push model for configurations was a mistake and got basically replaced by the pull model where the server sends workspace/configuration requests.

The client should still send workspace/didChangeConfiguration notification so that the server can clear caches if it caches configurations. But it should not send any values since values can differ based on the scope used in the workspace/configuration request.

[mickaelistria]

- the initialization options it supports. I agree with @LaurentTreguier <https://github.com/LaurentTreguier> that a server should work with an empty literal as well and simply assume a set of defaults. Just to give examples and food for thought, VSCode CSS language server

requires explicit enablement for sass, scss and so on; and VSCode JSon language server doesn't pre-load a typical list of JSon schema. Both assume client discover this settings by reverse engineering VSCode and repeat the same settings. The question is what drove the developers of those LS to rely on those options instead of making them default? It'd be interesting to get their POV on this question.

Having a push model for configurations was a mistake and got basically replaced by the pull model where the server sends workspace/configuration requests.

Still, the expected type is `any[]` which means that it's some LS specific settings that require specific integration. I don't think the flow of the operation was the issue here (while it's still good to know it was improved), it's really than any `any` leads to the unspecified world and specific effort of integration between client and LS, which is the opposite of LSP goal. I believe instead of specifying some operations with `any`, it's better to leave these as extensions. For clients, it's a similar effort to support one or the other, and it's not reusable between LS, so the protocol should remain strictly made of specified, portable, reusable operations, and whenever there is `any`, consider deprecating the operation basically because it's not specified enough to be useful by most tools.

[dbaeumer]

I disagree here. The reason is that the fact that initializationOptions is in the spec say that this property should be used and not any other random property.

I still think that it is a fair thing to require a server to depend on some initializationOptions. But I do fully agree that these need to be speced by the server (and not be reverse engineered from code) and that server should work with a resonable default set if they are not provided. Same is true for settings.

I do fully agree that the spec need to spec this assumptions.

@aeschli any comments on why the CSS language server can't work with a reasonable default set ?

[felixfbecker]

One pattern I saw emerge is that many language servers interpret initializationOptions as containing user configuration, i.e. the same that is sent in workspace/didChangeConfiguration or in response to workspace/configuration. But LSP doesn't actually really say this, it is very vague on what initializationOptions actually means:

User provided initialization options.

It doesn't use the term "configuration", but it does say "user provided" (not client provided).

The reason why language servers use it for configuration is because there is otherwise no way to read configuration in initialize. workspace/didChangeConfiguration is only sent after initialize returned (if at all), and workspace/configuration is not among the whitelisted requests allowed during initialize.
The problem is that since initializationOptions is not clearly defined, most clients do not send configuration in it.
Could LSP just be clearer about what initializationOptions is intended to be used for (maybe with an example in the spec)? And could workspace/configuration be whitelisted to be used during initialize?

[dbaeumer]

I will clarify the spec in a way that the initializationOptions is typically something that could be passed on the command line when starting the server. It shouldn't be user configurations.

I am actually against whitelisting workspace/configuration. If a server needs the configuration to register providers it should use dynamic registration instead of static registration which allows to mix workspace/configuration with registration calls.

[dbaeumer]

Please ping if you think dynamic registration is not the right path to go.

[mickaelistria]

I will clarify the spec in a way that the initializationOptions is typically something that could be passed on the command line when starting the server. It shouldn't be user configurations.

I disagree with that. The initializationOptions can be a good way to guarantee that user settings are passed immediately to the LS before to starts up. I think that basically, the initializationOptions have to be a super-set of the didChangeConfiguration as there are case where we want the configuration immediately. From a client perspective, the didChangeConfiguration is over-used, hard to maintain and is semantically often used with wrong semantic since several LS use it even to retrieve a default configuration. Eclipse Corrosion had an important discussion with RLS on that matter, and the resolution that initializationOptions can contain a mirror of didChangeConfiguration improved things a lot: rust-lang/rls#1026

[felixfbecker]

I am actually against whitelisting workspace/configuration. If a server needs the configuration to register providers it should use dynamic registration instead of static registration which allows to mix workspace/configuration with registration calls.

@dbaeumer I agree for determining whether a provider should be registered or not, but a server might need configuration during initialisation for a lot of reasons. For example, a loglevel or logfile, whether file watchers should be set up with polling or OS events, the HTTP endpoint of a service that needs to be contacted, whether dependencies should be installed, if yes an access token for that, the path of an external tool that needs to be shelled into, something like JAVA_HOME or GOPATH, ...
Requiring to delay all of these after initialize complicates a lot of things for no apparent reason. Also not every client supports dynamic registration, and these clients should gracefully degrade in functionality, i.e. they should work with a static set of capabilities from server initialize and work with restarting the server instead of not working at all.