Experiment: remote file system

[jrieken]

This is an experiment about allowing extensions to contribute something like a remote file system to VS Code. For now, only loading and storing is tackled, no discovery nor creation of files/folders. Also, only text files are considered for now, no binaries etc.

To try this have an extension (using proposed API*) that does the following:

    vscode.workspace.registerFileSystemProvider('foo', {
        onDidChange: new vscode.EventEmitter<vscode.Uri>().event,
        resolveContents(resource) {
            return `It's ${Date.now().toString(23)} o'clock`;
        },
        writeContents(resource, value) {
            // pretending this happened...
            return;
        }
    })

*) Enable proposed API by having this line in your package.json "enableProposedApi": true, and for IntelliSense copy the most recent version of vscode.proposed.d.ts to your extension.

[mention-bot]

@jrieken, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bpasero and @egamma to be potential reviewers.

[bolinfest]

Good news! I got this working with my existing demo with very few code changes: bolinfest/vs-code-preview-html@4e7647b

As you can see from the commit message for that commit, I'm seeing resolveContents() getting called additional times. Otherwise, things seem to be working as expected.

I'm also excited to see that both methods can return a Thenable, though I didn't try returning errors from resolveContents or writeContents yet to see how those were surfaced in the UI.

I also haven't tried wiring up any remote LSPs yet. I may not be able to do that until Wednesday.

[jrieken]

FYI - I have removed the need for the --remote-flag, having this behind proposed API should be enough protection. I have updated the description accordingly.

I'm seeing resolveContents() getting called additional times. Otherwise, things seem to be working as expected.

Can you provide a little more detail? Today, we throw things away when the last editor or tab closes, when then opening a file again we go back the truth. Is that what you are seeing or are there other unexpected calls?

I'm also excited to see that both methods can return a Thenable, though I didn't try returning errors from resolveContents or writeContents yet to see how those were surfaced in the UI.

Yeah, error handling should be working (tho is untested 🙈). Also, as suggested we should look into some sort of streaming API that enables providers to deliver a file in chunks. That and a long list of other features is to be defined, let's for now focus on the MVP

[bolinfest]

@jrieken Are you sure things are still working now that you dropped the --remote thing? I rebuilt and now I can't get my extension to work anymore.

[bolinfest]

@jrieken Yep, I went back to what you had before (the top of the stack of two commits) and rebuilt:

git checkout 16c00672fad01309cfbb4a6caa7674fc04feba81
./scripts/npm.sh install

and then I launched with ./scripts/code.sh --remote nuclide and things worked again.

[bolinfest]

Also, I had to add this to vscode.proposed.d.ts when I added that file to the typings/custom folder in my extension (I don't know if that's the right place to put it, but that's what someone suggested):

import { Event, Uri } from "vscode/vscode";

I also got an error on readonly name: string; in Terminal, so I just commented out Terminal altogether for now.

[jrieken]

Are you sure things are still working now that you dropped the --remote thing? I rebuilt and now I can't get my extension to work anymore.

Yeah, pretty sure. I have a simple sample here and that still works. Do you see any errors or does the debugger break on any errors?

Also, I had to add this to vscode.proposed.d.ts when I added that file to the typings/custom folder in my extension (I don't know if that's the right place to put it, but that's what someone suggested):

I usually just put it next to my extension sources, tho it shouldn't really matter as long as there is a "recent" version of vscode.d.ts and a recent version of TypeScript. The definitions of both files should be merged. What error are you seeing in the terminal?

[siegebell]

The errors in vscode.proposed.d.ts are a result of an out-of-date vscode engine version; updating this will fix the issue.

[bolinfest]

FYI, I updated to c510eff and did a clean rebuild and everything looks good!

[jrieken]

Merging onto master such that it can be tried out easier.

[felixfbecker]

@jrieken as I understand it, this selects the correct provider based on the URI authority (host and port), correct? Wouldn't it make more sense to select it based on the URI scheme? E.g. have one handler for file: URIs, one for ftp:, etc.

[jrieken]

Wouldn't it make more sense to select it based on the URI scheme?

Totally! Just a lot harder to implement because for some reason our code makes a ton of assumptions on the file and untitled schemes. Once this becomes real it will be based on scheme

[sqs]

It would be nice if extensions could specify in activationEvents that they should be loaded in order to provide the file system for a given authority. I have a POC of this working (with a few other changes, such as routing on scheme not authority, but you can just ignore those):

https://gist.github.com/sqs/3c8dc223d5d418f09cec4a68020d9038#file-remotefileservice-ts-L98

This requires the extension API FileSystemProvider to always return promises (never just string).

We are trying out this new API and will hopefully have more patches/experiences to send along. So far, it's great. We've moved all of our remote file system code to an extension.

[jrieken]

Totally, the scheme-activation event has been already discussed for the virtual documents api and will be part of this, no doubt about that.

[siegebell]

Reopening tabs upon vscode restart needs to work with remote files.

I think this also needs schema activation events -- so that vscode can wait for the associated extension to activate, giving it a change to register a file system, before requesting that the remote file be loaded.

[bolinfest]

Could we get some sort of "authority activation event" for now? In the meantime, we could try keeping the set of open files from the authority written to some scratch data and use that when VS Code reopens?

…

On Thu, Jul 27, 2017 at 8:29 AM, CJ Bell ***@***.***> wrote: Reopening tabs upon vscode restart needs to work with remote files. I think this also needs schema activation events -- so that vscode can wait for the associated extension to activate, giving it a change to register a file system, before requesting that the remote file be loaded. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#30337 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAoB_f_7Xlxa6V73elBfw9W-VXJKbrNpks5sSKzGgaJpZM4OS6WU> .

[jrieken]

Could we get some sort of "authority activation event" for now?

Unsure, while this is experimental I'd go with the * event. Reopening files is on deck, in general files from remote source should "feel" no different that local files.

[dlebu]

@jrieken I am trying to launch VSCode from a webpage using the URL mechanism described here, and open a remote file system automatically. Is this expected to work given the current state of the remote file system implementation?
If not, what would be a good way to achieve that?

[jrieken]

Is this expected to work given the current state of the remote file system implementation?

No and unsure how we could make it work today...