multi-process FE concept (for NG3)
I would normally post this in just the openice/linuxice forum, but I thought it may be useful to share the idea and possibly get input from others on the concept.
The concept: A multi-process frontend for in-vehicle-infotainment systems.
For nGhost2, we developed an extensive IPC (Inter-Process-Communication) interface and toolkit library with the hopes that other apps would be developed that used the toolkit to maintain look/feel yet remained a separate process. Communication between apps still worked because of the IPC engine.
In theory, this allowed the Linux window-manager (WM) to do it's job instead of nGhost taking over that role (traditionally, 3rd party apps are embedded into the FE and the FE assumes WM functions). In which case, the user could use a window manger like compiz and add eye-candy and some usefulness (via the Scale and Expose Plugins). An example of some eyecandy effects via the window manager can be found here.
One other benefit of this method was that one app couldn't possibly crash the entire system, or nGhost.
In nGhost2 (ng2), this ideology didn't play out how we would have hoped. It suffered from major flaws. The Toolkit was too cumbersome to create separate apps quickly, and IPC communication was equally cumbersome to setup to facilitate proper communication. Because of these flaws, eventually nGhost's plugin system replaced the multi-process ideology.
The popularity of google chrome has lead me to revisit the idea. As you may know, each tab in the chrome browser is essentially a separate process with a narrow IPC lane to facilitate communication. If one page crashes, it simply kills the tab... chrome still runs as if nothing ever hit it.
I have proposed we evolve the ideas of ng2, fix the issues in a new roll-out: nGhost3 (ng3).
To illustrate the architecture plans for ng3, I must first explain the different components involved in the system and what their roles are:
NDM - nGhost Desktop Manager
In and *nix environment it is common to have a desktop manager. GDM on GNOME (stock ubuntu also), KDM on KDE, etc. Traditionally, these Desktop Managers facilitate multi-user logins and start the graphical session for the user that logs in.
In a system such as OpenICE, which is within usually a single-user environment (with autologin a must), no existing desktop manager would suffice. In the 1.0 platform, no DM is used, simply an autologin script and "startx".
NDM will take over the DM role in OpenICE post 1.0. It will facilitate autologin for single users, facilitate multi-user logins in a more mobile friendly way, and also act as a process owner for ng3-core. In addition to these, its primary role will be to facilitate a window layout system, and track all the loaded plugins.
ng3-toolkit
this is not a process, but a library of functions for plugins to draw look/feel consistent GUI elements such as buttons, listboxes, dials/guages, etc.
ng3-server
This is the hub of the ng3 system. It's main role will be to pass communication between plugins.
The server instance will be owned and started by NDM with all the plugins enabled on the system.
ng3-core
ng3-core is a child process to the ng3-server. It runs a single plugin.
ng3-plugin
a ng3-plugin is similar to any plugin. It inherits from some interface, and implements some functions. a plugin can be a graphical plugin that uses the ng3-toolkit, or a pure code plugin with no graphical interface.
Default Plugins
Icepanel, will be a default plugin along with an audio-device interface, and possibly some others.
plugin loading
WHen NDM logs in, it will start ng3-server. It will also keep an IPC handle of that core. Then NDM will start loading plugins. NDM can do this in two ways, in embedded mode, NDM will pass a message to the ng3-server to create a new window. NDM will then start up a client-core with that plugin and pass it the server IPC handle and the window ID for the clent core to embed itself in the server.
In non-embed mode, the plugin will be loaded into a new client-core instance with a handle to the ng3-server in its own window.
When ng3-core loads with the new plugin, it will ask NDM via IPC where it should draw it's window and how large.
finally ng3-core will then register an icon for the plugin on icepanel so the user can switch between it and the other plugins. A plugin can also register additional controls on icepanel if it so needs/choses.
icepanel
In case you don't know the openice system, icepanel is a dock application for the purpose of exposing controls and launchers from applications that need to persist their controls across multiple screens. In pre-1.0, icepanel, nscan, and nGhost were the only separate process plugins that utilized the nghost IPC mechanism for communication.
Conclusion
In short, by implementing a multi-process FE system, the entire system can be more secure/stable, and utilize things like existing window managers for extra usability and eyecandy. This system also by nature takes advantage of multiple cores/processors (think atom 330 dual-core and the new 550 that will soon be released). The server still embed bypassing the window manager or can allow plugins in separate windows yet still maintain the same embedded look/feel that is expected in mobile systems.
Plugins are developed in a traditional manner yet still benefit from communcation method to other plugins and the main server and they don't have to worry about sharing the CPU with other plugins on a single-threaded/single-process design.
The idea is simple, but the devil is always in the details and implementation. I'm interested to hear what others think about the idea.
Questions? Comments?
