Open pchainho opened 7 years ago
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?
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
I guess this would require Admin GUis to use the msg bus: @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.
Yes, that is also my understanding, can you confirm @dvilchez ?
Yes, you both are right :)
@dvilchez have you tested SharedWorkers for this solution?
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.
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:
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
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.
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?
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
Summary of Slack Discussion:
In terms of impact at the Runtime Core and Runtime Browser:
hyperty-runtime://<runtime-domain>/<runtime-id>/<App URL without scheme>
@pchainho is the summary of slack discussion prioritized?
In terms of implementation tasks and its order, it would be something like:
@pchainho If you don't want to use a nested web workers polyfill the order should be:
if they work we would have the same behaviour than we have now except Admin GUIs. Next Steps:
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
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.
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.