2 ms·

I'm doing this. One difference is to be able to ditch Javascript and use a native language(Swift is the first one) to talk directly to webkit. The other diffe

I'm doing this. One difference is to be able to ditch Javascript and use a native language(Swift is the first one) to talk directly to webkit. The other difference is that the apps are "managed" as Chrome manages the renderer process, so in the end you have one manager process and one service process for each app and many process for the UI apps. The problem with Electron is that for each app, it will need many processes, and if you have more than one Electron app running, it will eat all the resources. With the architecture proposed, it will be more light as there will be just one instance of the manager processes, and unlike Electron they would not be isolated as they are all centrally managed, also the fact that it wont need to use JS, will also put less pressure on memory resources. It also uses RPC so that every app have a API that can be callable by others. This in turn can make it form a "network of apps" where the applications can consume the apis of the other apps installed. The RPC service is local first, but can fetch things in the "cloud" if the application needs to. For me this is my take on what "Web 3.0" should look like. I have a 0.1 version here and i'm just finishing the final touches before launching it.. Edit: Also i forgot to mention that the distribution of the application and resources(database and files) is over torrent with DHT routing, so you can share a unique address and serve your own applications over internet without depending on domains or a third-party hosting it for you.

politician 5y ago
Nice! If I understand correctly, the renderer process is shared across all apps, each app is either a service or a UI process, and all of the apps export an API that's routable from the local machine. Is that right? Do you need / want any help?
- oscargrouch 5y ago
  Its like this: You have one manager process and one GPU process for everyone. (Mind you that this is chrome based, but its quite modified i must say). Then for each application: You have a "service process" which is instantiated and is always running, this process asks for the manager to create its rpc service server. Then every rpc call is routed to it. This application service process is already coded by the developer so he defines what every api does and also how it respond to resources like pages, images, videos, etc.. (it also uses RPC by default to route resources.. but its through HTTP/2 giving its gRPC/Protobuf) This process, totally in control of the dev code also can hijack its own application launches, so its in charge of app launching and killing (from its own scope) Then theres the UI process which is akin to renderer and its also coded by the dev, where the renderer is in Swift so totally customizable (Imagine being able to control the C++ renderer events, lifetime, frames, etc.. of the chrome renderer process; in this case you do, with Swift), giving you have a lot of power. The developer control, codes and ship the service and the ui app. Once its installed, even without any UI, all other applications can consume its services over its RPC api, because there is a 'service process' running and serving those requests (imagine being able to deal with twitter or a google search api (all local and with the same tech) from your app that is specialized in something else) > Do you need / want any help? Yes of course! How can i reach you?

politician 5y ago

Nice! If I understand correctly, the renderer process is shared across all apps, each app is either a service or a UI process, and all of the apps export an API that's routable from the local machine. Is that right? Do you need / want any help?

oscargrouch 5y ago
Its like this: You have one manager process and one GPU process for everyone. (Mind you that this is chrome based, but its quite modified i must say). Then for each application: You have a "service process" which is instantiated and is always running, this process asks for the manager to create its rpc service server. Then every rpc call is routed to it. This application service process is already coded by the developer so he defines what every api does and also how it respond to resources like pages, images, videos, etc.. (it also uses RPC by default to route resources.. but its through HTTP/2 giving its gRPC/Protobuf) This process, totally in control of the dev code also can hijack its own application launches, so its in charge of app launching and killing (from its own scope) Then theres the UI process which is akin to renderer and its also coded by the dev, where the renderer is in Swift so totally customizable (Imagine being able to control the C++ renderer events, lifetime, frames, etc.. of the chrome renderer process; in this case you do, with Swift), giving you have a lot of power. The developer control, codes and ship the service and the ui app. Once its installed, even without any UI, all other applications can consume its services over its RPC api, because there is a 'service process' running and serving those requests (imagine being able to deal with twitter or a google search api (all local and with the same tech) from your app that is specialized in something else) > Do you need / want any help? Yes of course! How can i reach you?