Provide HTTP interface

[kardeiz]

I'm running into an issue where VSCode is a Windows app and rustup and rls are provided through the Windows Subsystem for Linux (WSL). See rust-lang/vscode-rust#144 and this Reddit post for more details.

The problem (as I understand it; I know nothing about VSCode development and haven't used RLS before) is with how child processes are forked; it seems to be assumed that the language server binary lives on the same OS as the VSCode app.

One thought I had is that it would be possible to launch the RLS server from WSL's bash and then connect to it in the rls-vscode extension. This seems to be possible as discussed here: microsoft/language-server-protocol#160. Running the RLS as an HTTP service would make this way easier to set up.

[nrc]

The LSP mandates using JSON over stdio, so I'm not sure if we can make this work on the VSCode side (without re-implementing the entire LSP client). That somewhat puts me off doing this. However, I hope on the RLS side, this wouldn't be too hard - we'd just need an HTTP implementation of the server io layer.

I wonder if there is a layered solution here - the RLS and VSCode continue to use stdio and we have a stdio <-> http <-> stdio proxy in between?

[kardeiz]

Thanks for the information, I didn't realize LSP mandated JSON over stdio. There was a link from microsoft/language-server-protocol#160 to an example (https://github.com/itemis/xtext-languageserver-example/blob/master/vscode-extension/src/extension.ts) that made it seem trivial to use a running HTTP service in ServerOptions, but I didn't really dig in much.

Over at rust-lang/vscode-rust#144, @jonasbb suggested using netcat as a stdio proxy server, which seems to work (although I don't know enough about the LSP and valid commands to do anything besides get error messages/crash it).

[djrenren]

I think LSP only requires JSONRPC. I don't think it mandates stdio as the transport, though many editors only support stdio connections.

[nrc]

Either way, I think given that clients expect stdio, this is not worth supporting, sorry.

[kardeiz]

I'm not opposed to closing this—I'm not using RLS right now and I haven't really been following the development of RLS.

However, won't this prevent usage where the compiler is on one computer and the editor/IDE on another? While not the most common scenario, it's not unreasonable, and will probably be increasingly common (e.g., thin desktop clients, RLS-aaS, etc.).

[nrc]

However, won't this prevent usage where the compiler is on one computer and the editor/IDE on another?

It will , but that is not currently well-supported by the LSP or any client I'm aware of. There is work to fix that, but I don't think it is likely to be released soon. When it is, it's probably worth re-visiting this.