Headless Remote Support

[sr229]

One of the things the official Visual Studio Code/ Visual Studio Codespaces has ahead of us is the ability to have one common frontend and have reproducible stacks with their own headless VS Code agents running inside of these containers. If we examine how VS Code Remote works:

We have a VS Code frontend capable of connecting to the container which itself has a headless instance of VS Code with extensions running in it.

code-server theoretically can implement this by implementing the same capabilities for a VS Code headless server.

Proposed strategy

We can implement this by going the extension-based route. This is basically the most publicly available way VS Code connects to a headless remote container. You install the extension which can be capable of handling containers, SSH, or WSL. These options on the Microsoft version can be installed independently from each other. For remote distributions (Codespaces) of VS Code, they have this preinstalled on the "frontend".

However, this also comes with another complexity in mind - we need to author a extensions that is capable of doing so, fortunately, all the APIs VS Code Remote uses is publicly available which makes it easier.

Theoretically if we have such a extension already we can bundle and have readily available as well for the VS Code Marketplace (and OpenVSX, if Coder decides to use that), it can be handled like this

# let's assume this is our "headless" server, nothing to change in the flags, we reuse the same port to expose the remote API
$ ./code-server --bind-addr=0.0.0.0:6972

# Now let's head over to another instance, this time, our "frontend" instance connects to it via a new argument or have our --bind-addr also serve the same purpose of connecting to it if it sees that there's a existing application connected to it.
$ ./code-server --connect-remote=remote-ijlr4.cdr.dev
$ ./code-server --bind-addr=remote-ijlr4.cdr.dev:6972

Advantages

Since we're aiming for VS Codespaces parity, this would allow code-server to be able to be a even more viable migration path for our venerable VS Codespaces users who likes to selfhost. This also opens other possibilities such as better integration paths for third party applications

Use cases

Coder Enterprise and Cloud IDE platforms

This is very relevant to Coder Enterprise and other Cloud IDEs such as Gitpod and Eclipse Che - as this would allow ISVs to seperate out the IDE itself from the reproducible containers. Since we can go the VS Code Remote path, we just update the IDE frontend and the containers can update themselves since the Remote extension will overwrite the code-server binary inside the container (since we're aiming for parity here after all).

Users Migrating from VS Codespaces

VS Codespaces users will be looking for a feature-parity equivalent of Microsoft's offering. As we don't have a confirmation that that GitHub Codespaces will get self-hosted options, this would allow code-server to have a early lead and snatch out of the main reasons some of the users of VS Codespaces came in the first place - the self-hosted option.

This would be a good long term strategy and would allow code-server to gain a early lead against Microsoft competition-wise on implementing one of the features VS Codespaces got sold in the first place - and this would allow as well a free open-source alternative to VS Remote for those FOSS junkies out there who hates the MS EULA.

[code-asher]

It would be nice to have complete parity. This is about implementing the remote extensions right? Let's track this here: #1315