The GNOME developers envisage that such a Linux app will be offered as a single file. This “app image” will contain the executable program, along with any required data files and libraries that may be needed. A manifest file within the image will identify the programming interfaces that must be provided by the system on which the application is to run. “Bare”, for instance, could mean that only the kernel ABI is required, while “system” will request various standard libraries that are typically included in Linux distributions; “gnome-platform-1.0″, on the other hand, could identify the full set of programming interfaces that are considered stable by the GNOME project.
In a blog post that describes various corner points of the developers’ current app format deliberations, GNOME developer Alexander Larsson writes that the entire concept is to go hand in hand with efforts to improve app isolation. For example, the developers plan to use techniques that are also used for containers to mount each app image in a separate area. Only the programming interfaces that are listed in the manifest will be available in these areas. The apps are not planned to have direct access to a user’s home directory.
“Portals” will be provided for exchanging files with the system and for interacting with other apps, with a functionality similar to that of Android intents. As portals, the system, and apps can offer features such as “open file” or “take picture” that can be requested by an app, users will need to authorise access before the portal provider can grant it. This authorisation is supposed to be given implicitly, as The H‘s associates at heise open learned at FOSDEM. For example, when a portal user requests a photo, the camera app that provides the portal could authorise access when the user presses the shutter button. When opening a file, the main system’s open file dialog would act as the portal provider; the app will only be given access to the selected file once the user has pressed the “open” button.
Data exchanges with the portal are to be handled via a D-Bus-like Inter-Process Communication (IPC) protocol that operates on the kernel level. Two such solutions already exist – but they are both maintained independently of the Linux kernel because they were rejected by the kernel maintainers of the appropriate Linux kernel subsystems. Kernel developer Greg Kroah-Hartman has said that he is planning to work on such a solution, which is one of the main reasons why he attended the GNOME Hackfest.
The developers’ plans have matured further than Larsson’s short blog post may imply; however, their implementation will likely take a lot of time and effort. The developers’ deliberations are also bound to spark extensive discussions. At present, the Linux distributions themselves make application software available in program packages that are co-ordinated between each other and are easy to set up. Installing a newer program version or software that is not part of a distribution, on the other hand, is often not quite as easy.