Snippets don't work when Plugin Host is not colocated with Back End

[tsmaeder]

In Che, we have come across this issue: eclipse-che/che#16502. The problem we're running into is that we resolve the snippets contribution to a file uri here: https://github.com/eclipse-theia/theia/blob/master/packages/plugin-ext/src/hosted/node/scanners/scanner-theia.ts#L424

This is not a problem as long as the plugin host runs on the same machine as the theia back-end, but it starts failing if the plugins are installed on a remote host.

Since even VS Code is moving to a solution where the plugin host can be remote, I would propose that we treat resources contributed by plugins as a special kind of resource with it's own uri scheme pluginresource. We already server plugin resources from under /hostedPlugin/<pluginId>/path/to/resource. I propose we use this for all plugin-related resources (like snippet files)

[akosyakov]

Could you elaborate how is it going to work? In VS Code they have vscode-remote scheme but it is not for extensions, but look up any remote resources. A URI with vscode-remote scheme should have an authority part with host and port that VS Code knows where to forward such request. On remote host there is a URI translator to translate incoming remote URIs to file URIs and outgoing file to remote URIs. Do you mean the same approach? But rename vscode-rename scheme to plugin-resource. I think we need another name then since it won't be relevant to plugins only for us as well, i.e. theia-remote.

[tsmaeder]

I'm working on a PR for the snippets case which will land later today. We're already serving plugin resources here: https://github.com/eclipse-theia/theia/tree/master/packages/plugin-ext/src/hosted/node/plugin-reader.ts#L45.
The problem with the host/port approach is that remote plugin hosts may not be accessible from the browser: at least in Che, that's the case.

[akosyakov]

I thought we will use then fs provider for such scheme and downstream products should have a proper fs provider which can handle dispatching instead of having custom HTTP endpoints. Also such URIs should be absolute as we discovered before? And current endpoint does not handle them?

[benoitf]

using uri protocol or fs provider looks like an implementation details

[tsmaeder]

@akosyakov you mean having a PluginFileSystem? That's certainly an option, but it would not replace the custom http endpoint, since we need publicly accessible url's for stuff like icons that the browser reads itself (not via websocket).

[akosyakov]

Ok, agree, we will need to support in different places.

[tsmaeder]

...thinking about where plugin-resource would be the appropriate resource scheme....

[tsmaeder]

I've opened #8468 as a basis for discussion on the way forward. It fixes the case of snippets for Che.

[tsmaeder]

I've been experimenting with implementing a plugin file system as a well-known instance of of vscode.FileSystemProvider that resolves paths from "pluginresource" schemes relative to the plugin folder.
This works well on the plugin side. The problem now is this: on the browser side, we simply don't know where plugins are deployed.

theia/packages/plugin-ext/src/common/plugin-protocol.ts

Line 763 in 03dbe0d

simply does not provide that information.
We already have a (largish) PR open that would remedy that problem: #8437