Runtime Instance shared by more than one App eg in different Tabs

[pchainho]

Summary made by @antonroman from https://github.com/reTHINK-project/dev-runtime-core/issues/111

To summarize, we should focus on three possible solutions to check which of them meets more reTHINK requirements.

1. intertab communication using localStorage: This solution has been discussed in reTHINK-project/core-framework#137 it could work but it has several drawbacks: reTHINKS iframes need to be loaded from the same domain (one of this iFrames wouldn't load the whole runtime but would interact with the runtime loaded in the other tab).
2. intertab communication using sharedWorker: SharedWorkers are defined here: https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker They are supported both from Chrome and Firefox. The solution sound more natural than the localStorage-based. Maybe the runtime should have always a sharedWorker, if another sharedWorker is detected then it should communicate with it ti use its runtime instead of deploying the rest of files of the core-runtime. Any feedback is welcome.
3. intertab communication using channel messaging: in the doc(https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API/Using_channel_messaging) it claims to be able to communicate two documents via a SharedWorker so it sounds as a higher abstraction layer to use sharedworkers but it seems that it should be possible to do what we need.

This should not be needed for NodeJS, since there should be a one to one relationship between NodeJS instances and App instances.

See reTHINK-project/core-framework#137 to keep discussing the localStorage approach and discuss sharedWorkers and Channel API in this issue.

[pchainho]

From your analysis, option 2 (sharedWorker) seems more promising and I like the idea of always having a sharedWorker that would be detected before a new instance of the runtime is created.: Would it be possible to make some experimentation to validate this approach before we go further in the discussion?

If it works we could also analyse the usage of SharedWorks to implement Protostub / Hyperty sandboxes, thus sharing network connections and Hyperty instances among several Apps / Hyperties deployed in different tabs. Pls note this discussion has an impact on the decision about the implementation of the P2P Stub sandbox .

One issue we should clarify with SharedWorkers is about closing the tab where the runtime SharedWorker was first loaded: is the SharedWorker destroyed?

[dvilchez]

The first think comes to my mind was this issue https://github.com/reTHINK-project/dev-runtime-browser/issues/17 where we suggested to use a web worker instead of an iframe to host the runtime. But it looks like spawn sub-workers is supported now https://developer.mozilla.org/en-US/docs/Web/API/Worker.

Then I started checking the code and I found a possible problem. The PoliciesGUI requires direct access to runtime instance and to DOM elements. Components inside a web worker don't have access to DOM tree. The same problem for identity manager who opens a popup to let the user log-in.

Is it feasible to remove these dependencies from the runtime in order to load the runtime in a sharedworker? /cc @pchainho @antonroman @AnaSLCaldeira @gamdias

[pchainho]

I guess this would require Admin GUis to use the msg bus: @gamdias ?

[gamdias]

From what I understood, the Runtime Core will be running in a shared-worker, while the administration GUI's will be running in an iframe? And the communication between these components is performed using the message bus?

If this is the case, I see no problem at all.

[pchainho]

Yes, that is also my understanding, can you confirm @dvilchez ?

[dvilchez]

Yes, you both are right :)

[pchainho]

@dvilchez have you tested SharedWorkers for this solution?

[antonroman]

We are in the process to test it but it requires several changes in the existing code. David is modifying the code, for example the references to window and the persistence manager can only use indexDB (not localstorage).

According the specification creating Webworkers inside a Webworker is possible so we think there is not any stopper to get it working once all the not usable references are modified. As it is complicated to test the rest of the code at this moment, we are planning to test the creation of webworkers inside the webworker and make sure it works as expected.

[dvilchez]

Hi @pchainho,

I have made some progress on this task, you can see them on runtime_shared branch. Some of the problems discovered until now are:

• little support of WEB API inside workers (no localstorage for example)
• no access to DOM tree

But the problem I am facing right now is a design problem related with the runtime-core. Until now we had only one application sandbox, but now we need at least one application sandbox for each context connected to the shared runtime. Each one of these application sandboxes need its own reference to the port where the application is connected.

I don't know if you have something in place to overcome it, let me know. In other case we need to discuss this asap.

/cc @antonroman @vitormsilva @shumy

[dvilchez]

Another one, nested workers are not supported in chrome right now https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5R3B4RN4GHU. Firefox supports it.

[pchainho]

little support of WEB API inside workers (no localstorage for example) no access to DOM tree

This shouldn't be a problem. Core components should not need the DOM tree nor the localstorage since now we are using indexeddb.

But the problem I am facing right now is a design problem related with the runtime-core. Until now we had only one application sandbox, but now we need at least one application sandbox for each context connected to the shared runtime. Each one of these application sandboxes need its own reference to the port where the application is connected.

yes, we have to carefully analyse this situation. Probably we need a diagram showing how an App is deployed when there is already an installed runtime. For the Hyperty deployment, the sandbox is first instantiated and then we pass to it the hyperty source package to be deployed. But the App it will be already loaded and instantiated in its own sandbox when it starts interacting with the Hyperty Runtime, right? Let's discuss this in slack

Another one, nested workers are not supported in chrome right now

why do we need nested workers ? is it related with the creation of web workers from the runtimeUA / Registry that with this feature would be inside a share worker?

[dvilchez]

yes, we have to carefully analyse this situation. Probably we need a diagram showing how an App is deployed when there is already an installed runtime. For the Hyperty deployment, the sandbox is first instantiated and then we pass to it the hyperty source package to be deployed. But the App it will be already loaded and instantiated in its own sandbox when it starts interacting with the Hyperty Runtime, right? Let's discuss this in slack

ok

why do we need nested workers ? is it related with the creation of web workers from the runtimeUA / Registry that with this feature would be inside a share worker?

yes it is

[pchainho]

Summary of Slack Discussion:

• a new type of sandbox for Hyperties and Protostubs that need to have access to some web apis namely to WebRTC, is needed independently of the this discussion. lets call it windowSandbox.
• the windowSandbox would be implemented with iFrames.
• the Runtime Registry will select the appropriate sandbox implementation according to constraints defined in the descriptor of the hyperty or protostub. See step 12 here
• the support of nested web workers would be defined as a Runtime Capability
• until Chrome does not support nested web workers, the Runtime UA would decide to deploy protostubs in a windowSandox
• as soon as Chrome supports nested web workers it will decide to deploy in a "normal" web worker sandbox. This will not require any change in the runtime source code, only in the runtime descritor

[pchainho]

In terms of impact at the Runtime Core and Runtime Browser:

• the RuntimeUAStub would still create an iFrame with the Admin GUI components inside but no runtime core that would now be executed as a shared worker. The Admin GUI components would communicate with the Runtime Core components through the Msg BUS
• App Sandboxes are created by RuntimeUAStub on Registry (or runtime UA) request, as today. The difference is that there will be more than one. The identifier of each AppSandbox should be derived from the APP URL, something like hyperty-runtime://<runtime-domain>/<runtime-id>/<App URL without scheme>
• In addition, the RuntimeUA can also ask the RuntimeUAStub to create Sandboxes outside the runtime core. This may be requested for iFrame based sandboxes as well as webworkers in case nested workers are not supported by the browser

[dvilchez]

@pchainho is the summary of slack discussion prioritized?

[pchainho]

In terms of implementation tasks and its order, it would be something like:

• [ ] Runtime deployment in the Shared Worker and update interface communication between RuntimeUAStub and Shared Worker interface- Quobis
• [ ] - iFrame creation with GUI Managers by RuntimeUAStub (it should be just a question of removing everything that is not GUI Manager) - Quobis
• [ ] Update Admin GUIs to use msg bus for the communication with the core runtime - INESC
• [ ] App Sandboxes creation by RuntimeUAStub on runtime UA request - Quobis
• [ ] - RuntimeUA and Registry update to support more than one AppSandbox. The identifier of each AppSandbox should be derived from the APP URL, something like hyperty-runtime://// - ALB / INESC
• [ ] - windowSandbox implementation based on iFrame - Quobis
• [ ] - Update RuntimeUA to select the appropriate sandbox according to constraints defined in the descriptor of the hyperty or protostub. - ALB
• [ ] - Update RuntimeUAStub to create, on runtimeUA request, iFrames or Web Workers, outside the runtime core and then deploy there components. - Quobis

[dvilchez]

@pchainho If you don't want to use a nested web workers polyfill the order should be:

• windowSandbox implementation based on iFrame - Quobis (I need to test this)
• Runtime deployment in the Shared Worker and update interface communication between RuntimeUAStub and Shared Worker interface- Quobis
• Update RuntimeUAStub to create, on runtimeUA request, iFrames or Web Workers, outside the runtime core and then deploy there components. - Quobis

if they work we would have the same behaviour than we have now except Admin GUIs. Next Steps:

• Update Admin GUIs to use msg bus for the communication with the core runtime
• RuntimeUA and Registry update to support more than one AppSandbox. The identifier of each AppSandbox should be derived from the APP URL, something like hyperty-runtime://// - ALB / INESC
• Update RuntimeUA to select the appropriate sandbox according to constraints defined in the descriptor of the hyperty or protostub. - ALB

[pchainho]

I've created the implementation tasks, accordingly.

Since Shared Workers are not supported yet on Web Views, we have to distinguish core sandbox implementation for standalone Apps and for Browsers