KDE 4.1 API Reference akonadi
Akonadi Design
The main components are:- The Client Library (libakonadi)
- Server
- The Control
- Agents (resources)
- Storage
In the diagram below you can see a rough schematic view of Akonadi:
Akonadi Components
The Client Library
Every client application can access the Akonadi service directly via the D-Bus and an IMAP-alike protocol; however, for easier implementation and a better abstraction the library libakonadi is provided, which handles all the low level stuff and provides a Qt based API for all the functionality Akonadi provides. libakonadi works on all kinds of data and knows nothing about the type of the data. For the type specific tasks libkabc and libkcal should be used, which are positioned above libakonadi, and perform the conversion from the raw storage format to convenient Qt/KDE objects.Server
The Server is a process which provides an API to store arbitrary data over an IMAP interface into a relational database. The advantage of IMAP is the mature state of the protocol and its capability to handle large quantities of data. Whenever items are added to or removed from the Storage, the Server will emit a signal over its D-Bus interface to inform other components. Also, as defined in the IMAP standard, a simple type of search is supported, so you can query for all items of a special mime type or for email-specific fields. For more complex search queries, another component, the SearchProvider, is included.Agents
Agents are processes which are controlled by the Akonadi server itself and which are able to work on the cache of the Storage. In the current design there are two types of Agents:
- Autonomous Agents
- Resources
Resources are processes which load data from an external data source, store them in the cache of the Storage and keep track of changes on both sides to keep the external data source and the cache synchronized. Resources can be grouped into profiles, where one Resource can belong to different profiles. Profiles are useful in use cases like this: You have configured a local Resource and a groupware server Resource. You want both to be shown in the address book application but for synchronization with your mobile phone only the data from the local Resource is of interest. So the easy solution is to create a profile 'view' which both the local Resource and the groupware server Resource belong to, and a profile 'synchronize' to which only the local Resource is assigned. Now you just have to tell the application which profile it should use to access the data.
The Control
The Control process is the 'brain' of the system. It starts the Storage and Resource processes and monitors them, so that if one of these processes crashes, it restarts them immediately. Furthermore it provides a D-Bus API with the following functionality:
- Managing Resources
- Managing Profiles
- Notifications when the state of Resources or Profiles have changed
