Views
Architecture/Documentation/Security/Accounts
Contents |
Overview
The accounts subsystem provides a storage solution for user accounts. Applications which need to store and access user settings for the service they provide over a user account will use the Accounts API. Instant messaging, e-mail, calendar and sharing are examples of such applications.
The accounts subsystem also allows service providers to install plugins which will take control of the account settings UIs which are used by the end user when he/she edits the user settings on the service they provide.
An account management UI would use two kinds of plugins:
- Provider plugins: these will handle the installation of the account on the device (and optionally could handle the account creation on the remote server as well), and handling of the account global settings.
- Service plugins: these will handle the service settings for a specific service.
In the general case of an account supporting N services, when editing this account an accounts UI would load at most one provider plugin and N service plugins; note that the same plugin can support multiple services, and in some case a plugin might not be needed at all.
Basic dependencies
- Qt :: Qt. Many utility classes and templates from Qt (such as QString, QObject, QList) are being used.
- Essentials :: Base Essentials :: glib. The libaccounts-glib is linking to the glib library.
- Essentials :: Base Essentials :: libxml2. The libaccounts-glib uses libxml2 to parse provider and service template files.
Interfaces provided
| Interface name | Interface type | Interface scope | Interface state | Required credentials | Description |
|---|---|---|---|---|---|
| libaccounts-qt | library | Platform | Stable | None | Account management API. This API provides access to the account storage: retrieval, editing and creation of accounts. A change notification mechanism is implemented in order to let different processes operate on the same data simultaneously.
The library also provides means to enumerate the account providers and services currently installed in the system. |
| libaccounts-qt | library | Nokia MeeGo | Stable | None | Account management, for glib applications. Provides the same functionalities as libaccounts-glib described above. |
| libaccount-ui | library | Platform | Stable | None | Accounts UI interface to be used for handling accounts UI plugins. The library should be used by applications willing to use the account plugins, as it implements the plugin loading functionality. |
Table 1: Interfaces provided
Interfaces required
| Domain/subsystem | Interface name | Interface type | Description |
|---|---|---|---|
| Data Management :: Content Framework | sqlite | library | The sqlite library is used for storage of account settings. |
| Essentials :: Base Essentials | dbus-libs | library | Change notification is implemented using D-Bus. The notification mechanism is internal to the accounts subsystem and no D-Bus API is exported. |
| MeeGo Touch Framework | libmeegotouch | library | The libaccounts-ui library uses MeeGo Touch to access graphical UI elements. |
| Security :: Single Sign-On | libsignon-qt | library | Single Sign-On is used to verify user credentials. |
Table 2: Interfaces used
Structural view
Components of the Accounts subsystem:
| Name | libaccounts-glib |
| Purpose | Access to accounts DB and service data |
| Source Packages | libaccounts-glib |
| Interfaces Used | sqlite, dbus-libs |
| Interfaces Provided | libaccounts-glib |
Table 3: Description of libaccounts-glib
| Name | libaccounts-qt |
| Purpose | Access to accounts DB and service data |
| Source Packages | libaccounts-qt |
| Interfaces Used | libaccounts-glib |
| Interfaces Provided | libaccounts-qt |
Table 4: Description of libaccounts-qt
| Name | libaccounts-ui |
| Purpose | Helper classes for interfacing with account plugins |
| Source Packages | libaccounts-ui |
| Interfaces Used | libaccounts-qt, libmeegotouch |
| Interfaces Provided | libaccounts-ui, libAccountPlugin |
Table 5: Description of libaccounts-ui
| Name | Account plugins |
| Purpose | Implementation of UI components for creating accounts and editing account settings (both service specific, and global settings). While they are not strictly part of the account subsystem, account plugins can be written by third parties to support more complex setups that involve communicating with other components in order to create or edit accounts. |
| Source Packages | Plugin/provider specific |
| Interfaces Used | libaccounts-ui, libAccountPlugin, libaccounts-qt, libmeegotouch |
| Interfaces Implemented | Account plugin interface |
Table 6: Description of account plugins
Behavioral view
The accounts subsystem doesn't rely on any deamons; instead, every client using the libaccount-{qt-glib} library implicitly adds a DBus match rule in order to receive change notifications from other processes using the library. The match can be restricted to a specific service type (for instance, e-mail applications should instantiate the account manager with the service-type parameter set to "e-mail"), in order to limit the number of process wake-ups to those of effective relevance to the application. In any case, the account subsystem doesn't generate or require any periodic activity, and it's reasonable to assume that accounts settings are not being periodically rewritten by any client application. So, most of the IPC concerning the accounts subsystem is happening during account creation/editing in the accounts UI; otherwise, all clients are reading account settings in their local process, by implicitly accessing an SQLite DB.
As such, the account subsystem itself doesn't have any direct impact on the boot time or application start-up time.
Get Value
The following diagram presents how to get an individual value from an existing account.
Here are the required steps:
- Create a Manager for the service type the application is interested in (for instance, "e-mail").
- Get list of all the accounts that support that service type.
- Get individual account object (this causes the instantiation of a new account object).
- Pointer to account is returned.
- Get list of all "e-mail" services from account.
- Account get all services from manager.
- Manager creates a new service object for every service in the resulting list.
- The service list is returned to Account.
- ServiceList is returned to application. In most cases this would be a list consisting of only one element, except in those cases where the same account provides different services of the same type (for example, on a Google account one might have "YouTube" and "Google Video" services for the service type "sharing").
- Application selects the desired service
- Application get value from Account
- Value is returned to application.
Data storage
All the account settings managed by the accounts subsystem are stored in a single SQLite database located in the user’s home directory. Static configuration data are shipped along with the service plugin packages and are installed under the /usr system directory; rpm packages take care of installing and removing them.
Development
As far as account functionality is concerned, applications using the accounts subsystem can be developed in a chroot, and executed both on the target device and in the chroot environment itself, without any differences in functionality.
Performance
General Performance Considerations
The performances of the Accounts subsystem heavily depend on SQLite performances, as this is the database being used for storing the account settings.
A typical account will consist of less than 5 records in the SQLite database, plus 1 record for each service enabled on the account; an experienced internet user will have a few dozens of installed accounts.
The records in the database are fairly simple, consisting mostly of a pair of key and value (with values being typically strings, integers and booleans); the size of the accounts database can be reasonably estimated to be below 100KB.
There are no real time requirements known.
Memory
| Explanation | Size [kB] | |
| Flash/OneNAND | Packages | 500 |
| Flash/eMMC | Account settings database | 100 |
| RAM/Idle | Memory footprint when account libraries are loaded | 200 |
| RAM/Peak | Memory footprint when libraries and plugins are loaded, account settings are loaded and accounts are being edited | 2000 |
Runtime
The most frequent scenario of usage of the Accounts subsystem is application initializing its accounts’ data: Accounts libraries will be loaded along with the application, which will need to list the accounts enabled for the specific service(s) it uses, and load their settings. Once the accounts are loaded, the impact of the libraries on the system is negligible.
Power Consumption
Disc access happens only when loading accounts (which typically happens on application startup) and when editing them.
Security
Accounts settings are not sensitive data.
Open items
No open items.