2 ms·

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

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?

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?