Designs

Build infrastructure on Intel x86-64 Introduction The current Apertis infrastructure is largely made of hosts based on the Intel x86-64 architecture, often using virtualized machines. The only exceptions are: OBS workers used to build packages natively for the ARM 32 bit and ARM 64 bit architectures LAVA workers, which match the reference hardware platforms While LAVA workers are by nature meant to be hosted separatedly from the rest of the infrastructure and are handled via geographically distributed LAVA dispatchers, the constraint on the OBS workers is problematic for adopters that want to host a downstream Apertis infrastructure. [Read More]

Infrastructure maintenance automation Introduction This document describes the goals and the approaches for automating the management of the infrastructure used by Apertis. It will focus in particular on release branching since the new release flow implies that Apertis will need to go through that process two or three times more than in the past on each quarter. Goals Data-driven Separating the description of the desired infratructure state from the tools to apply it nicely separates the two concerns: in most cases the tools won't need to be updated during branching, only the desired infrastructure state changes. [Read More]

This document extends the higher-level Applications and Security design documents to go into more detail about the permissions framework. Applications can perform many functions on a variety of user data. They may access interfaces that read data (such as contacts, network state, or the users location), write data, or perform actions that can cost the user money (like sending SMS). As an example, the Android operating system has a comprehensive manifest that govern access to a wide array of functionality. [Read More]

List design The goal of this list design document is to establish an appropriate architecture and API design for the list widgets in the Apertis platform. Historically, the roller widget has provided a list widget on a cylinder with no conceptual beginning or end and is manipulated naturally by the user. For non-cylindrical lists there was a separate widget with a different API and different usage. The goal is to consolidate list operations into a base class and be able to use the same simple API to use both cylindrical lists and non-cylindrical lists. [Read More]

Web portal caching Introduction The purpose of this document is to evaluate the available strategies to implement a custom, single-purpose browser restricted to a single portal website that hosts several HTML/JS applications. The portal and the visited applications should be available even if no Internet connection is available. If a connection to the Internet is available, the locally-stored contents should be refreshed. Locally-stored copies should be used to speed up loading even when the connection to the Internet is available. [Read More]

Clutter and Multitouch Introduction This document explains Collabora's design about several issues related to the main UI toolkit used in Apertis: Clutter. Multi-touch This section describes the support for multi-touch (MT) events and gestures in the Apertis middle-ware. It will be explained which requirements Collabora will support and the general architecture of MT on Linux and X.Org. When we mention MT in this document, we refer to the ability of applications to react to multiple touch event streams at the same time. [Read More]

Writing ConnMan plugins The plugin documentation in ConnMan was improved and submitted upstream. The documentation about writing plugins ca be found on ConnMan sources in the following files: doc/plugin-api.txt, src/device.c and src/network.c. Example plugins are plugins/bluetooth.c plugins/wifi.c, plugins/ofono.c, among others. Customs ConnMan Session policies The documentation to create Session policies files for specifics users and/or groups can be found in ConnMan sources doc/session-policy-format.txt. The policies files shall be placed in STORAGEDIR/session_policy_local directory, where STORAGEDIR by default points to /var/lib/connman. [Read More]

Preferences and persistence Introduction This documents how system services and apps in Apertis may store preferences and persistent data. It considers the security architecture for storage and access to these data; separation of schemas, default values and user-provided values; and guidelines for how to present preferences in the UI. The Applications Design, and Global Search Design documents are relevant reading. The Applications Design and the Global Search Design reference the need for storage of persistent data for apps. [Read More]

Robustness Introduction This design identifies circumstances that, though undesired because of the risk of loss of functionality, cannot be completely avoided and provides suggestions for dealing with them in such a way that as little functionality as possible is lost. Note that improving D-Bus’ robustness is a topic that will be covered in a later stage in its own design document. About securing D-Bus services, please see the security design. [Read More]

Software Development Kit Definitions Application Binary Interface (ABI) Stability: the library guarantees API stability and further guarantees dependent applications and libraries will not require any changes to successfully link against any future release. The library may add new public symbols freely. Application Programming Interface (API) Stability: the library guarantees to not remove or change any public symbols in a way that would require dependent applications or libraries to change their source code to successfully compile and link against later releases of the library. [Read More]