Provide a client-side protocol message that allows server to request execution of a command

[kdvolder]

There is existing protocol for a client to request a server to execute a command. We have several places where we want to have the reverse. The server asks the client to execute command instead.

This would work in the same way as the client->server message: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#workspace_executeCommand

We could use the same name workspace/executeCommand or use a different name to emphasize that the message flows in the opposite direction e.g. workspace/clientExecuteCommand.

This proposal may seem a bit strange, if we assume that all commands are defined by the server itself. However that is not typically the case in practice. In practice the server contributes commands and these commands get entered into some type of client-side command registry. There are actually more commands that exist client-side than just those defined by the server itself. (e.g. some commands may be defined by the client itself, or some commands may defined by other servers with which the current server interoperates somehow).

For this proposal to make sense, all we have to assume is that some commands 'exist' on the client that are not defined by the server itself. We do not need to assume a specific mechanism by which these commands are defined. So it should be possible to agree on a 'standard' mechanism to request the execution of a client-side command.

For some context...

We have run into several cases where we needed this and in each case it was handled by some custom protocol extension.

The latest of these is here: eclipse-wildwebdeveloper/wildwebdeveloper#543 (comment)

There has also been some discussion in other related LSP tickets, which I can sumarize again here:

#430 is probably the most closely related, one part of what it needs/asks for is a mechanism for server to request client to execute a command.

#432 has a discussion around whether commands live in a 'shared/global' name space or whether the commands belong only to a specific client<->server session.

With a shared namespace one server could define a command and another one could use it (e.g. in code action, or also in a potential executeClientCommand request. With 'per session namespace' this wouldn't be possible.

#642 is about defining a mechanism for a server to discover what commands a client actually supports.

These tickets digressed into long discussion which do not seem immediately actionable.

So I propose in this ticket to narrow the scope a bit, to make it more actionable.

Let's avoid getting into discussions about:

• how exactly commands may be defined on the client side (we just need to accept that they can be defined/exist somehow)
• whether client-side commands are in a global name space
• whether/how a server can discover which commands are supported on the client

Instead I intend this ticket to be only about adding a single protocol message that allows the server to request the client to execute a command.

[dbaeumer]

@kdvolder would you be willing to work on a PR for this. Both for the spec and the vscode-languageserver-node implementation?

[mickaelistria]

I agree with the use-case, which I think is interesting, powerful and fits well in the protocol (as there are already operations to invoke commands the other way round).
About the operation, I think it would better be client/executeCommand.

[kdvolder]

would you be willing to work on a PR for this

Yes. I've not tried extending the 'vscode-languageserver-node' implementation before, but I'm willing to give that a try.

@dbaeumer Would it be best to dive right into the implementation, or would it better to work on the protocol description first? I was thinking it's probably easiest to discuss the description and once we are generally in agreement it seems fine, then try to implement it as described.

[kdvolder]

^^^ I've just created a PR against the spec markdown. Let me know if needs clarification or a bit more discussion (e.g. are we all in agreement about the name of the protocol message as client/executeCommand? To me names like client/executeCommand, workspace/executeClientCommand or workspace/executeCommand are all good names and I don't have a real preference. So I just went with @mickaelistria suggestion and called it client/executeCommand.

[rwols]

Related: #983