In the world of information, both effective methods of its exchange and methods of its storage are necessary. Each modern system uses several different DBMS, each of which has its own advantages and was chosen to meet specific needs. However, diversity in formats raises the problem of compatibility and collaboration with resources. To solve the problem of data duplication and incompatibility of formats, the Akonadi project was launched - the fourth of the KDE4 pillars we reviewed.

Akonadi was created as an extensible system for storing personal data and metadata for desktop computers, providing simultaneous access to read, write, and create requests. In addition, Akonadi includes several components, such as search and cache, which allows you to get quick access to data, and notifications about changes.

What is the essence of Akonadi and why is it needed?

')
Let's start with why all this is needed. In KDE 3, personal information management applications (such as Kontact) store their data and settings separately, duplicating identical data. A bunch of KMail and KResources has already exhausted all its capabilities, it is time to solve the problem of shared resources and asynchronous access to them: in KDE3 Kontact holds 6 copies of your address book in RAM! In addition, the goal was to create something more standardized - such an open project cannot be developed without taking into account the needs and directions of development of other large and important projects. Therefore, it was decided to create a client-server system based on standard data storage and exchange formats, with D-Bus support, and independent of the platform and development tools. The implementation of this idea was Akonadi.
A reasonable question arises - is it not enough that various groupware solutions have already been created that promise to work with any types of data? Immediately, we will explain: Akonadi is not a groupware server! In contrast, Akonadi is an intermediate repository, a level of abstraction for personal data. It is akin to the previously reviewed Phonon and Solid.


This diagram shows the main aspects of the Akonadi architecture. Everything is based on a centralized data repository, which is accessed using a protocol that is not tied to a specific platform or programming language. Over this protocol is a set of APIs that are used to access personal information in the repository. There are two types of Akonadi customers. The first type is applications such as Kontact, Evolution, KOffice. The second type is resources that allow the central Akonadi repository to exchange information with external data sources. Such sources can be groupware servers (for example, GroupWise or OpenExchange), other data storage mechanisms (iCalendar, vCard files), or standard protocols (IMAP, POP, etc.).

This is far from a complete diagram and it shows a simplified example of use. Akonadi is designed as a flexible system available to a wide range of applications and resources. Part of Akonadi's concept is that adding new APIs, relevant customers, and sources should be as simple as possible.

This architecture has several advantages over what was in KDE3:

1. Personal data is kept in memory in a single copy.
2. The system is centralized, so any changes occur at once, allowing all components to work with the latest data versions.
3. The Akonadi architecture is designed to organize asynchronous data exchange (there should no longer be an application “fading” during data exchange).

What will Akonadi give to ordinary users?

For the user, the pros are not so obvious, but still quite substantial. As mentioned above, all applications use the same storage, so there is no need to duplicate data in memory. Accordingly, less resource intensity. In addition, an extended version of the IMAP protocol is used to access the repository, which increases the speed of data retrieval. The same IMAP protocol provides basic search capabilities that can be implemented and extended in each individual application.
Everyone probably knows such Plasma applets as a calendar, leave a note, etc. - they all share the same Akonadi share. And if earlier you could see data synchronization problems between applications (for example, if Kopete changed contact data, while Konversation was viewing them at that time), now synchronization issues are taken over by the Akonadi server and the data is automatically updated everywhere (for example, birthdays are calendar plasmoid). Moreover, data synchronization with a remote server becomes completely transparent for the user.

In addition, it will be possible to more easily integrate personal data into other KDE applications. For example, besides the user's name, it will be possible to display his photo in the file properties. The data exchange components between the Akonadi server and the data source (for example, the same groupware server) are divided into separate processes, which helps to avoid crashing the entire system in case of an error. The failed component process can simply be restarted and the data will be reloaded.

What will Akonadi give to programmers?

Since Akonadi takes care of receiving and storing data, which is usually the most difficult part in developing PIM, it is now easier to develop PIM applications. For example, the frame of the mail client Mailody using Akonadi was written in 10 minutes.

The main features of the Akonadi architecture:
* Shared personal data cache

• Resource independent design
• Extensibility
• Basic offline access, recording and playback of changes
• Basic conflict detection and resolution system
• Resources are grouped by profiles.
• The data elements are composed of a plurality of independently derived parts.

* Simultaneous access allows for background processes regardless of interface

• Synchronize mail, calendar and address book with remote servers
• Synchronization with mobile devices
• Allows the semantic environment infrastructure to access personal information
• Archiving
• Indexing
• "Out-process" search

* Multi-process design

• Insulation krashey
• Large items do not block the entire system.
• Linking on IPC allows the use of proprietary components
• Thin client installations can share components for greater scalability.

What does independent of types of resources mean? Groupware, IMAP, MS Exchange, vCard and everything else are separate resources that are supported by different engines. Similar to Phonon and Solid, engines on different platforms provide theoretically unlimited possibilities for working with various types of data sources. Developers are provided with a single API for work, so writing applications for working with personal information becomes much easier.
The overall design of Akonadi and its components is described in the API documentation . More information can be found in the project page on Techbase .

Information taken from Akonadi's official website, Akonadi articles on Russian Wikipedia , as well as from an interview with Tobias Koenig , one of Akonadi's leading developers, for kubuntu-de.org. Presentations slides, posted on the official Akonadi website, were also used.

This is a cross-post of my article with WeLinux.ru