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

[pchainho]

Summary made by @antonroman from reTHINK-project/dev-runtime-core#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 How to use a reTHINK runtime deployed in a different tab 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 reTHINK-project/dev-runtime-browser#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.