The concept designs are a set of technical documents covering many aspects of the project, written through the history of the project, taking into account the status of the project at that time. These documents cover topics that have been researched but not necessarily implemented in Apertis at the time of writing.

Information in these documents may be outdated, but nonetheless provide important context for the decision making process and overall vision of the project.

Many of the concept designs can be found on the concept design portal.

Web Runtime

Definitions web runtime a set of rules, supporting libraries, App Framework and SDK integration to allow development and integration of web and hybrid apps targeting the Apertis system web app an application using web technologies such as HTML, CSS and JavaScript, integrated on the system through the web runtime native app an application targeting the Apertis system using the Apertis UI toolkit for its user interface, developed in either C or one of the other supported languages such as JavaScript hybrid app a native app that includes a web page as a piece of its user interface; it may use the web runtime infrastructure but not necessarily does Overview The web runtime will be provided through a library that mediates the interaction between the WebView and the system, and a launcher. [Read More]

Compositor security

The compositor is the component of Apertis that is responsible for drawing application windows and other graphical elements on the screen. Background The compositor is a process responsible for combining surfaces (texture buffers) representing application windows into the single 2D image displayed on the screen. In an X11 environment, it combines the roles of a window manager and a compositing manager. In a Wayland environment, it also takes on the role of the display server from X11. [Read More]

Egress filtering

This way to the egress! — attributed to P. T. Barnum An application that handles confidential data might have a security vulnerability that leads to it becoming controlled by an attacker. This design aims to mitigate such attacks. Assumptions We assume that the user has some confidential data (for example the contents of their address book), accessible to a particular application bundle, and that an attacker's goal is to gain access to that confidential data. [Read More]

Content hand-over

Content handover is when an application is asked by the user to open a file it doesn't know how to handle or to start a service it is not responsible for providing. For example, a browser just finished downloading an epub file and the user now wants to open it. The browser will ask the system to start the application responsible for dealing with that file. Another example would be a map application in which the user located a destination and now wants to navigate. [Read More]

Content hand-over Use-cases

Use-cases for content hand-over This page collects the use-cases for “one-shot” content handover, as currently mediated by the Didcot service. Some related use-cases which have been associated with the Didcot content-handover service during discussion of its API, but which we believe are sufficiently distinct that they should be examined separately, are collected on Content hand-over/Related. Where use-cases describe a requirement for a particular UI/UX behaviour, this is intended to be shorthand for a requirement that the platform provides enough control and enough information that the behaviour described is implementable. [Read More]

Interface discovery

Various features on Apertis require a way to discover the applications and/or agents that implement a particular set of functionality. We refer to the “API contract” for this set of functionality as an interface. Use cases A global search user interface requires a list of agents that can act as “Auxiliary Sources” (see §6.2 in the Global Search design document). For example, a Spotify client might register itself as a search provider so that searching for a term in a global search will find artists or songs matching that term. [Read More]

Points of interest

Use-cases General points of interest Third-party applications (the “provider”) might be aware of general “points of interest” for mapping. For example, an accommodation booking app-bundle might be aware of the locations of hotels, either from a particular chain if the app-bundle is for that chain, or for all hotels if the app-bundle is for a general service like Trip Advisor. It must be possible for a third-party app-bundle to provide these “points of interest” to a navigation app. [Read More]

Sharing

Use cases App bundles’ functionality may include a feature of the form “send file to another user”. Suppose the user is viewing a file in some application, either built-in or a store application. Sharing menu The current application must be able to obtain a list of potential sharing recipients from the platform, sufficient to display a sharing menu similar to the one in Android. This list could include actions such as “send via MMS”, “attach to an email”, “send via Skype” or “share on Facebook”, each with the icon of its associated app bundle. [Read More]

App Store Approval

This page will eventually collect all the guidelines we recommend for app-store curators. The general principle should be that anything that crosses a trust boundary should be checked. For now, here are the design documents and wiki pages that are relevant to this topic. This list is not exhaustive: Applications design document Multi-user design document Security design document Sensors and Actuators design document Geolocation and Navigation design document Application Layout (the layout, bus names, etc. [Read More]

Data sharing

This page describes design patterns that can be used for inter-process communication, particularly between applications and agents in the same or different app-bundles. We consider a situation in which one or more consumers receive information from one or more providers; we refer to the consumer and provider together as peers. Use cases Points of interest should use one of these patterns Sharing could use one of these patterns Global search (see ConceptDesigns) currently carries out the equivalent of interface discovery by reading the manifest directly, but other than that it is similar to Query-based access via D-Bus Selecting an initiator The first design question is which peer should initiate the connection (the initiator) and which one should not (the responder). [Read More]