blueprint

Rationale

The goal of the download service is to offer a download API in Ubuntu Touch and then Ubuntu Desktop builds for system services and apps.

This allows:

• suspending or terminating apps initiating downloads to save/reclaim resources while downloads are ongoing
• implementing policies such as downloads on wifi mobile data connections centrally

Interface

The service will be exposed over DBus, as most other middlewares and services, the following pages provide documentation for those applications willing to use the DBus API, however, applications are recommended to use the QML bindings of a C library wrapping the service that will be provided.

• DownloadManager - Entry point of the API the manager allows an application the creation of a Download or a GroupDownload.

• Download - Object that represents the download of a single file in the manager. Exposes methods to interact with the download as well as signals that are emitted when progress is performed.

• GroupDownload - Object that represents the download of 2 or more files that should be taken as an atomic operation. The interface is similar to the one found in downloads.

The DBus service ensures that applications do not interact with downloads that were not created by the application AppArmor sandboxing.

Initial implementation

This describes the scope of the initial implementation.

Apps may:

• add downloads
• specify additional headers
• specify whether the download may happen over mobile data connection
• start/pause/resume/cancel downloads
• get notified on download progress
• list their own downloads

QML bindings allow registering downloads and showing a progress bar.

Apps need a special permission to access the download service.

TODO: do we need a special permission for mobile data downloads? This might require separate DBus entry points with our current AppArmor DBus implementation.

TODO: are downloads in memory, in an app chosen pathname, in a download service chosen filename? TODO: limits (size of download, timeouts etc.)

Apps may be killed and restarted between the start and the end of a download.

We don't want to remove downloads over a reboot, but it's acceptable to cancel in-progress downloads over a reboot.

Downloads for one application should be removed when that app is uninstalled.

Download manager implementation

In a latter iteration, we will add the capability to manage a user-visible central list of downloads. Apps will be able to flag a download as user-visible and users will have a dedicated "Downloads" app to see/open/remove completed downloads.

TODO: do we need a special permission to access the central list of downloads?

Roaming support

In a latter iteration, add API to block/allow downloads on a roaming mobile data connection.