Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RRS: Resolveable Resource Specifier #14

Closed
frank-dspeed opened this issue Nov 10, 2022 · 0 comments
Closed

RRS: Resolveable Resource Specifier #14

frank-dspeed opened this issue Nov 10, 2022 · 0 comments

Comments

@frank-dspeed
Copy link

frank-dspeed commented Nov 10, 2022

The Concept of RRS maps directly to the MOJO::IPC dispatcher concept of ResourceIds that get resolved back to the real Resources

Why?

How?

  • the serviceWorker is the main browser context entrypoint for system modules builtIns it offers API's for that
  • modifing the URL Implementation inside v8 makingit RRS Compilant with backward compat to whatwg url parsing.

Usecases

Problem: Allow the user to load and use local code with the browser context

it is mainly a concept of exposing dynamic module loading to userland via filePicker or other methods.

Problem: integrating a external graphics context directly into the canvas element or iframeelement videoelement imageelement

Allow Nativ HTML Elements to interact with dynamic registered nativ components.

Creating a fullscreen snapshot if there would be a component called gpu::0 via directly memCopy of the GPU buffer.

<img src="gpu::0"></img>

Internals

The Compositor (Shell, Browser) is able to expose IPC Channels to the serviceWorker / nodejs / deno which is able to translate the gpu::0 string to a real resourceId inside the IPC System and this way get a Handle Back for it to access.

the serviceWorker solves also write locks and all that for multiple context instances.

Successor over fetch proposal

as this allows to implement fetch as is with all its context restrictions as a none restricted fetch would be simply done by the net::https://domain.com/target.file call like it is already done internal on the C++ side.

browser implementations need to request permissions for dynamic module loads while host runtimes do not if they do not want to. it is a Runtime Shell depend.

think about it as Resolve Able Urls that do not get resolved by the Network Stack they are Internal ResolveableReferences defined as string Specifier.

this defines a Winterop component system using RRS as Specifiers Identifiers

Resolving a a module via reference inside v8

// result can be used after that via MessageChannels ports send to the context
// result can be used to supply fetch responses.
serviceWorker.load(fileHandle) // browser secure way without permissions as perimissions come from the fileHandle Request. Only localFiles
serviceWorker.load() // browser secure way without permissions as perimissions come from the fileHandle Request.
serviceWorker.load("net::https") 
serviceWorker.load("fs::/home/path/shared.so") 
@jasnell jasnell closed this as completed Jan 13, 2023
@Ethan-Arrowood Ethan-Arrowood transferred this issue from another repository Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants