remote: allow loading resources for managed remote authorities #185720
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This implements basically the same 'loopback' that vscode.dev does via a service worker to load resources for managed remote authorities in Electron. Except instead of using a service worker, it uses a buffer protocol via a new 'vscode-managed-remote-resource' scheme. It finds the window that the request came from and asks it to load the remote file. I initially looked at folding it into the existing 'vscode-remote-resource' scheme, but we needed a "buffer protocol" for this and it seems http protocols can _only_ respond with an HTTP URL, which we don't want here.
deepak1556
reviewed
Jun 21, 2023
| return callback(notFound()); | ||
| } | ||
|
|
||
| remoteResourceChannel.value.call<NodeRemoteResourceResponse>(NODE_REMOTE_RESOURCE_IPC_METHOD_NAME, [url]).then( |
There was a problem hiding this comment.
I am not familiar with the details of the issue this PR is trying to solve, but just asking from Electron API adoption perspective. In the current implementation, when the renderer process encounters a resource with vscode-managed-remote-resource scheme, the main process is tasked with sending an ipc to renderer for resolving and loading the resource via some fileservice which then again streams the data back into the renderer via another ipc internally for the protocol handler implementation.
Is there any way the resource can be read from the main process to make one less IPC call ?
alexr00
approved these changes
Jun 21, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements basically the same 'loopback' that vscode.dev does via
a service worker to load resources for managed remote authorities in
Electron. Except instead of using a service worker, it uses a buffer
protocol via a new 'vscode-managed-remote-resource' scheme. It finds
the window that the request came from and asks it to load the remote
file.
I initially looked at folding it into the existing 'vscode-remote-resource'
scheme, but we needed a "buffer protocol" for this and it seems http
protocols can only respond with an HTTP URL, which we don't want here.