Latest revision as of 09:05, 7 April 2011

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

Table 1: Interfaces provided

Interfaces required

Table 2: Interfaces used

Structural view

Components of the Accounts subsystem:

Table 3: Description of libaccounts-glib

Table 4: Description of libaccounts-qt

Table 5: Description of libaccounts-ui

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.

Get value sequence diagram

Here are the required steps:

1. Create a Manager for the service type the application is interested in (for instance, "e-mail").
2. Get list of all the accounts that support that service type.
3. Get individual account object (this causes the instantiation of a new account object).
4. Pointer to account is returned.
5. Get list of all "e-mail" services from account.
6. Account get all services from manager.
7. Manager creates a new service object for every service in the resulting list.
8. The service list is returned to Account.
9. 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").
10. Application selects the desired service
11. Application get value from Account
12. 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

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.