Contents |
The Contacts Engine glues together locally stored and online data and provides it to the Contacts application and other components. Services offered by the Contacts Engine are any application that needs to access contacts data. The Engine is also responsible for storing data to tracker using the defined contacts ontology, getting updates from internet services using feeds or other notification messages, and linking together data coming from different sources that is related to a single contact. Note that this collection of remotely stored contacts is different than the synchronization use case, because in this case the central storage for the data is not a device but a remote server accessed by several sources. Permanent data is read from tracker asynchronously and stored.
Qt Mobility Contacts provides a data API for enumerating, managing, synchronizing, searching and matching contacts and receiving notification about contacts. This is utilised by providing a backend plugin for Qt Mobility, qtcontacts-tracker
contactsd (gitorious.org/qtcontacts-tracker/contactsd) is a daemon to collect buddy information (such as status and presence information) from all the user's telepathy accounts and store it to tracker. Contacts' information, stored by contactsd to tracker is accessed by applications through QtContacts and qtcontacts-tracker.
There are no hardware requirements specific to these subsystems, the main constraints on the hardware are the performance requirements common to the platform.
This chapter presents the major dependencies and the public Interfaces of the Subsystem using the tables below.
| Interface name | Interface type | Description | subsystem |
| QtContacts | API |
Synchronous and asynchronous procedural calls for contacts data access and manipulation.QtContacts interface is provided by QtMobility, ContactsEngine is providing interface implementations: 1) qtcontacts-tracker | QtMobility/QtContacts |
| Interface name | Description |
| libtelepathy-qt4 | Used to receive contacts info, status and presence. Presence is then written to tracker. Used also to initiate call and chat. |
| libqtsparql | Data storage,
Storing and reading contacts, contacts presence and location information. Receiving data change updates. Reading information about feeds Using NIE ontology – basic (meta) ontology Using NCO for contacts read, write, get notification about data update Using NMO for reading info about messages SMS Message, RSS/Atom Ontology -reading, writing IM status Backup of all contacts data |
The Contacts data model follows Tracker’s Nepomuk Contacts Ontology (NCO). The model is extensible and supports custom data fields that can be added by the user or applications. For more information about the schema see http://www.semanticdesktop.org/ontologies/nco/[1]
Contacts is in middleware and application layer and uses libraries in the SDK (Qt, ...) and system services offered by the SDK (D-Bus, Service FW).
The functionality of the Contacts subsystem can be developed in SDK environment.
All components are hosted on gitorious.org:
The contacts database is stored in tracker.
Variant configurability (confml) includes only one setting; numberMatchLength is used to define number of last digits of normalized phone number strings used to compare phone numbers. e.g. when matching contact with phone 012-345-67-8-9-11 to phonenumber (QContactFilter::MatchPhoneNumber) 07-05-67-89-11. In some of Europe variants (where numberMatchLength is 7) they would be the match, while in some of Chineese variants (numberMatchLength is 11) they would not match.
Large memory footprint of shared libraries: Qt, libqsparql, QtMobility/QtContacts – estimated around 40MBs of virtual memory for shared libraries - shared between other applications.
IPC that tracker contributes to client connection:
Contacts subsystems don't open a network connection, access the network directly, or have timers/heartbeat mechanisms.
As the main storage for contacts data is tracker, most of the security of the data depends on tracker. When data is accessed either directly from tracker, or via Qt Mobility API, the contacts components have no role in verifying whether the access to the data is authorized.
Qt Mobility is based on Qt Plugin - security here depends on MeeGo Security FW implementation for shared libraries and plugins.
| # | Item | Status | Description |
| Security FW implementation for shared libraries and plugins | Open | Qt Mobility is based on plugins and security. | |
| Documentation of user interface components | Open | The documentation only currently covers backend components |