GNU/Linux

From wiki.gpii
Jump to: navigation, search

Notes:

  • The content on this page dates from November 2012. For other pages related to Linux, see the category "Linux".
  • Some people with disabilities prefer GNOME 2 over GNOME 3; GNOME 2 lives on in the MATE Desktop Environment, which also uses gsettings.
  • Ubuntu comes with different desktop environments, some of which can also be supported (at least partially) through gsettings. Adding support for Ubuntu Unity may be even easier than adding support for MATE.
  • Support for dynamic device reporting is currently more important than the addition of other desktop environments.


[DRAFT] Linux/GNOME implementation

The main purpose of this document is to describe, as much as possible, the Linux/GNOME implementation of Cloud4All.

Introduction

The Linux/GNOME Cloud4All implementation could be the easiest to achieve, and it is maybe due to several reasons.

Given the open source philosophy of the Linux/GNOME platform, the level of adaptability to the environment is undoubtedly high, the existing documentation is wide, the channels of communication with the platforms developers are well defined, and it is one of the most versatile environments for development purposes.

GNU/Linux, as well as being the core of the most popular distributions such as Ubuntu, openSUSE or Fedora, is adaptable to the needs of almost most type of devices like the Kindle’s ebook, Tomtom's GPS or the Android mobile phone ones. Regarding GNOME, it is one of the two most widespread free desktop platforms.

Since in both the GNU/Linux and GNOME projects free standards are used, they follow the specifications defined by the Freedesktop project. While providing a free software development platform, Freedesktop defines these free standards and tries to

  1. Collect existing specifications, standards and documents related to X desktop interoperability and make them available in a central location
  2. Promote the development of new specifications and standards to be shared among multiple X desktops
  3. Integrate desktop-specific standards into broader standards efforts, such as Linux Standard Base and the ICCCM
  4. Work on the implementation of these standards in specific X desktops
  5. Serve as a neutral forum for sharing ideas about X desktop technology
  6. Implement technologies that further X desktop interoperability and free X desktops in general
  7. Promote X desktops and X desktop standards to application authors, both commercial and volunteer


Thanks to these standard specifications and the other ones defined by GNU/Linux and GNOME, they pretend to offer a suitable and homogeneous system, from devices detection, software installation until the configuration storage system.

Cloud4All over GNOME/Linux

There are a multitude of technologies surrounding this GNOME/Linux implementation for Cloud4All. Some of these technologies are shared with other implementations. For to mention some of these technologies:

Shared technologies:

  • NodeJS
  • JavaScript
  • REST
  • JSON
  • XML
  • Web browsers


GNOME/Linux specific technologies:

  • GNOME Shell - It is the core user interface of the GNOME desktop environment.
  • GNOME ATs - The toolkit-neutral way of providing accessibility facilities in applications like the Orca screen reader.
  • GSettings - Configuration storage system
  • DBus - The Inter-process communication (IPC) open-source system for software applications to communicate with other ones.
  • Udev - The device manager for the Linux kernel.


Since both the Cloud4All components and the architecture flow are well defined in the wiki (wiki.gpii.net), we are going to focus with detail on the implementation of the Cloud4All over Linux/GNOME and its particularities.


User detection (User Listener), starting and stopping of the Flow Manager

User detection is the starting point of the system's personalization process. Some methods have been arise as entry points, and among others, for example:

  • USB/SD storage devices
  • NFC/RFID


In the case of the USB/SD storage devices, the one responsible for to start the Flow Manager will be an Udev rule. This Udev rule is responsible for checking the events from the kernel. When a USB/SD device is plugged in, the kernel create an event in udev, and the Cloud4All Udev rule checks if the recently plugged device has a token in its root directory, and if so, the udev rule will trigger the Flow Manager execution.

The process will be similar with the NFC/RFID devices, but in this case, Udev will not be the responsible one who fires the Flow Manager execution up, but a daemon or a service checking for the read result and sending it back to the Flow Manager.

Regarding the stop, the process will be the same, but in reverse. In the case of Udev, by detecting if the previously plugged device has been removed.

Although these are the first two and already demonstrable implementations, there are numerous possibilities, such as:

  • User/Password method
  • QR Codes
  • Barcodes
  • Facial or voice recognition
  • Fingerprints
  • Others


Device Reporter - Preferences Server - Matchmaker

After the execution of the Flow Manager, it's the turn for the Preferences Server, which is responsible to provide the preferences for the user, in a close to natural language and using an API REST.

Then, the Device Reporter gets the relevant data from the device, both from the hardware and from the software. In the case of Linux/GNOME the platform, OS version and GNOME version among many other stuff, will be provided. The detection of such Linux/GNOME elements is pretty simple because this can be possible by using some utilities:

  • Specific package manager for the distribution.
  • Plain, XML or JSON formatted text parsing.
  • GNU/Linux utilities. Scripting.


After the Device Reporter ends its commitment, its result is sended within the result from the Preferences Server one to the Matchmaker.

The Matchmaker uses the results received for to provide the required actions to be taken or the options whose will be provided to the system for the be properly configured to the user.


Auto personalization of the system - Lifecycles

After that, it's time to adapt the environment for the user, and to get this done, the Licecycle Manager is joining the game. The Lifecycle Manager drives the engagement and disengagement of the user customizations on the system. To do this, the Settings Handler is used for, and the Lifecycle Handlers know about the activation and/or deactivation of the aspects of the system, using Settings Handlers.

Is in this component (Settings Handler) where is the most of the work of the Cloud4All implementers, since they have to take into account each and every one of the characteristics that are desired to implement and the limits applied by the environment.

In the case of the Linux/GNOME platform, to accomplish this process we will need many components and technologies, but the level of adaptation to achieve is quite high. And, despite the many existing ways to store preferences, they are usually stored in a more or less homogeneous way (by technology).

To apply the customizations to some applications, services and other components, the implementers are expected to use the following technologies:

  • GSettings: Configuration storage system for the GNOME desktop. Services and applications.
  • DBus: Inter-process communication (IPC) open-source system for software applications to communicate with another desktop elements. Both at user and system levels.
  • GConf: The old configuration storage system for the GNOME desktop, and still used by some components.
  • JSON: JSON format.
  • YAML: YAML format.
  • XML: XML format.


Although these technologies currently cover most of possible adaptations, it also raises the need for to do other kind of actions in the system, such as installing additional software for to support some specific adaptation, or the alteration (or simplification) of the user experience by changing the look of the environment.

Regarding software installation, most of the modern GNU/Linux distributions use PackageKit (from Freedesktop), which makes the software installation distribution-agnostic and easier. Currently, you can operate with PackageKit by using DBus or by using the command line. Currently, the integration level of PackageKit into the distributions and their support is still not complete, so it may need to use the specific package managers from the GNU/Linux distributions like apt, yum, zypper or pacman.

There is another level of adaptability, which would require altering the graphical user environment (desktop) and/or modifying certain applications user interfaces. In the case of the desktop environment, GNOME provides to the GNOME Shell user the ability to modify or add elements and appearance of the desktop using extensions, easily and installed by the user. Regarding the modification of a certain application, some proposals must be provided to the GNOME platform and required modules for to accomplish a complete adaptation, so the Cloud4All will need the collaboration from the GNOME community.