vscode/extensions/vscode-test-resolver
Connor Peet f5427eed53
remote: first cut at 'inline' remote resolvers
For web, it seems the most feasible direction for resolvers as we make
existing remote extensions 'web enabled' is to allow them to run in the
extension host. However, in no case will there just be a simple
websocket we can connect to ordinarily.

This PR implements a first cut at 'inline' resolvers where messaging is
done in the extension host. I have not yet tested them on web, where I
think some more wiring is needed to mirror desktop. Also, resolution of
URLs is not in yet. I think for this we'd want to do some service-worker
-based 'loopback' approach to run requests inline in the remote
connection, similar to what I did for tunnels...

Resolvers are not yet run in a dedicated extension host, but I think
that should happen, at least on web where resolvers
will always(?) be 'inline'.

Most of the actual changes are genericizing places where we specified
the "host" and "port" previously into an enum. Additionally, instead of
having a single ISocketFactory, there's now a collection of them, which
the extension host manager registers into when a managed resolution
happens.
2023-04-18 15:54:20 -07:00
..
.vscode Add vscode-test-resolver 2019-05-22 16:41:26 +02:00
media Add icons for built-in extensions (fixes #81760) 2021-04-20 12:09:24 -07:00
scripts [testresolver] kill server on shutdown 2019-06-14 12:07:04 +02:00
src remote: first cut at 'inline' remote resolvers 2023-04-18 15:54:20 -07:00
.gitignore Add vscode-test-resolver 2019-05-22 16:41:26 +02:00
.vscodeignore Add vscode-test-resolver 2019-05-22 16:41:26 +02:00
package.json remote: first cut at 'inline' remote resolvers 2023-04-18 15:54:20 -07:00
tsconfig.json Start enforcing the tunnels API (#163187) 2022-10-10 10:10:24 -07:00
yarn.lock chore: update to electron 17 (#143223) 2022-03-11 00:51:37 +09:00