Revision as of 16:11, 28 January 2011

Communication History

Communication History is solution used to automatically log communication events, such as calls and messages. It contains the following components:

• commhistory-daemon, which works as a Telepathy client with Observer role: listens to Telepathy channels (text channels for messages and stream channels for call events). It saves the events to database. It uses libcommhistory for database access and data model creation (currently tracker is used, but in the past sqlite was used as well). When the model is updated in commhistorydaemon, it sends DBUS signals to all other instances of libcommhistory listening to these signals. It also implements notification handling on the recorded events (missed call, instant messaging, SMS, voicemail). It also provides a private DBUS interface for activating notifications, so that when the user taps on notification, it opens the related application using configured action strings (via MRemoteAction of MeegoTouch).
• libcommhistory is a library abstracting database access for messaging and call events, and for building Qt data models (lists) for applications using libcommhistory: call event model (call type: missed, dialed, received; sorted by: contact, time, type, service;), a conversation model, group model, SMS inbox model, class 0 SMS model, SMS sync model. It currently uses tracker as database, but using sqlite would be also possible (it was used before tracker). Qt Mobility will provide storage access methods for accessing Communications History. For UI applications that use different models than the ones provided by libcommhistory, the direct use of Tracker ontologies and SPARQL queries is adviced.

A summary of requirements relative to data logging:

• All communication shall be logged
  • Received call will be logged either as received call, missed call or dialed call. Depending on how the call was handled.
  • application shall support logging of the private chats.
  • application shall support logging of the group chats.
  • Log must be stored in persistence storage.
  • API to let applications manage the logged communication events.
• User data cleared on reflash or factory reset
  • User settings and data shall be cleared on reflash or Clear device.
  • User settings shall be clear on factory reset.
• Support Backup & restore for logs, accounts and settings
• Support Synchronization.

Behavioral view

A typical use case usually involves the following processes:

• commhistory-daemon;
• mission-control;
• connection manager;
• tracker;
• notification service;
• optional service implementation;
• conversations application.

Usually communication between them happens via session DBus, except telepathy-ring <-> oFono communication that uses system DBus. In certain cases/protocols, other IPC mechanisms are used. commhistory-daemon does not perform any periodic tasks, and only reacts to external events. commhistory-daemon should be started during boot in order to perform the following tasks:

• check unhandled incoming SMS messages and initiate their re-delivery;
• check voicemail MWI status from SIM card and activate/deactivate corresponding notification.

Its startup time including the initial checks takes around 3 sec.

End users interacts with the subsystem only via notifications. commhistory-daemon encapsulates remote actions for individual notifications and each notification group. The remote actions usually invokes the daemon itself which then redirects it to a final service. This is necessary in order to manage notifications and their content in the daemon. Other subsystems access the subsystem via telepathy interfaces. (The daemon also provides dbus service for contact authorization handling.) A typical usage scenario for the system would be receiving a SMS message or registering a missed call. The typical steps includes the following:

• observing a communication event like receiving a message or a call via telepathy Observer interface;
• logging a new event in tracker via libcommhistory;
• resolving contact details of event's initiator from tracker via libqt-contacts;
• publishing a notification for the end user via MeegoTouch notification service;
• notifying libcommhistory models in applications of changes.
• There are no high-level states which affect the subsystem behavior. Both commhistory-daemon and libcommhistroy are involved in most cases.

Sequence for sent and received messages:

• Telepathy channel interface
• commhistory daemon (observing the channel)
• daemon uses libcontacts API to find contact based on remote id
• CommHistoryModel stores event to database
• Messaging UI processes data through another CommHistoryModel instance via dbus
• Application view connected to the model

Typical queries from/to Contacts are:

• get all remote IDs (email, phone number)/transient contacts [sorted by date]
• get the contacts data asynchronously
• give communications history for a specific contact or given set of accounts.

Sequence diagrams for data access

Data storage

Events are stored in the Tracker database. Libcommhistory uses the local file ~/.commhistoryd/ids.dat to keep track of unique running event and group ids for use with device syncing. When used with sqlite database backend, database configuration settings are stored (sqlite3). Private database is stored in ~/.rtcom-commhistory/commhistory.db

Development

Communications History runs in Scratchbox.