I want to use the rpc interface for communication via stdin/out in wsl,
but currently RPC is tightly coupled to the control server. The control
server also speaks msgpack instead of JSON, since it deals with binary
messages. WSL won't, and we'll want to use JSON to interact with VS
Code, so some separation is needed.
This pulls out a base set of RPC types for use in both scenarios.
Currently these are only 'helper' structs that don't actually do any
i/o, but once I figure out the model I would like to have a cleaner way
to do i/o in a unified way as well.
For the control server, previously we basically handled all methods in
one big `switch` block with nasty macros, whereas now there's
nicer `register_a/sync` functions.
Some additional small refactors were needed to preserve the strict
ordering of server messages, since they need to be order else we get
decompression errors. This is the `start_bridge_write_loop`. As a small
benefit, this means we can avoid the relatively expensive async Tokio
mutex that we were using, and instead use the standard library mutex.
Fixes https://github.com/microsoft/vscode-cli/issues/563
If a new tunnel `--name` was provided but the existing tunnel was deleted,
the CLI would error out with a lookup failed message. Instead it now
recreates it like it normally would.
Adds support for running the tunnel as a service on macOS via launchservices.
It also hooks up observability (`code tunnel service log`) on macOS and Linux.
On macOS--and later Windows, hence the manual implementation of `tail`--it
saves output to a log file and watches it. On Linux, it simply delegates to
journalctl.
The "tailing" is implemented via simple polling of the file size. I didn't want
to pull in a giant set of dependencies for inotify/kqueue/etc just for this use
case; performance when polling a single log file is not a huge concern.
Implements an automatic local download fallback, similar to SSH
(cc @roblourens). If the initial download results in an error, either
in making the request or a 5xx, it'll try to fall back to making the
request locally and streaming it over the tunnel.
This abstracts the request client behing a "SimpleHttp" trait which
either uses to the native reqwest or uses the 'delegated' mode over the
socket.
The standalone CLI should detect and fall back to using and
system-installed VS Code instance, rather than trying to download zips
and manage its own VS Code instances.
There are three approaches used for discovery:
- On Windows, we can easily and quickly read the register to find
installed versions based on their app ID.
- On macOS, we initially look in `/Applications` and fall back to the
slow `system_profiler` command to list app .app's if that fails.
- On Linux, we just look in the PATH. I believe all Linux installers
(snap, dep, rpm) automatically add VS Code to the user's PATH.
Failing this, the user can also manually specify their installation dir,
using the command `code version use stable --install-dir /path/to/vscode`.
Fixes#164159
- Start separating a "standalone" CLI. This is a little awkward with clap-
derive, but I got it working. Detection of whether the CLI _is_
standalone is still todo.
- Remove the old ad-hoc update code for code-server, and use the update
service instead.
- Fix some of the "permission denied" errors people got while updating
before. We need to rename the old running binary, not just overwrite it.
