Pillars of KDE4. Akonadi

    Pillars of KDE4.  Akonadi
    In the world of information, both effective methods of sharing it are necessary, as well as ways to store it. Each modern system uses several different DBMSs, each of which has its own advantages and was chosen to meet certain needs. However, the variety in formats raises the problem of compatibility and collaboration with resources. To solve the problem of data duplication and format incompatibility, the Akonadi project, the fourth of the KDE4 pillars we examined, was launched.

    Akonadi was created as an extensible storage system for 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 quickly access data, and notifications about their change.

    What is the essence of Akonadi's work 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 the same data. The combination 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 considering 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 formats for storing and exchanging data, with D-Bus support, and not depending on the platform and development tools. The realization of this idea was Akonadi.
    A reasonable question arises - have not enough various groupware solutions already been created that promise to work with any data types? We ’ll explain right away: 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.

    Basic Akonadi Organization
    This diagram shows the main aspects of the Akonadi architecture. Everything is based on a centralized data warehouse, access to which is carried out using a protocol that is not tied to a specific platform or programming language. On top of this protocol, a set of APIs is organized 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 Akonadi central repository to exchange information with external data sources. Such sources can be groupware servers (for example, GroupWise or OpenExchange), other storage mechanisms (iCalendar, vCard format files), or standard protocols (IMAP, POP, etc.).

    This is not a complete diagram and it shows a simplified use case. Akonadi is designed as a flexible system, available to a wide range of applications and resources. Part of the Akonadi concept is that adding new APIs, relevant clients and sources should be extremely simple.

    This architecture has several advantages over what was in KDE3:
    1. Personal data is stored in memory in a single copy.
    2. The system is centralized, so any changes occur at a time, allowing all components to work with the latest versions of the data.
    3. The Akonadi architecture is designed to organize asynchronous data exchange (the application should no longer “freeze” during data exchange).


    What will Akonadi give ordinary users?



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

    In addition, it will be possible to more conveniently integrate personal data into other KDE applications. For example, in addition to the username, you can display his photo in the file properties. The components of the data exchange between the Akonadi server and the data source (for example, the same groupware server) are divided into separate processes, which helps to avoid an emergency shutdown of the entire system in case of an error. The failed process of the component can simply be restarted and the data will be downloaded again.

    What will Akonadi give programmers?



    Since Akonadi takes care of receiving and storing data, which is usually the most difficult part in developing PIM, now developing PIM applications has become easier. For example, the framework of Mailody using Akonadi was written in 10 minutes.

    Key features of the Akonadi architecture:
    * General cache of personal data
    • Resource-independent design
    • Extensibility
    • Basic access offline, record and play changes
    • Basic Conflict Detection and Resolution System
    • Resources are grouped by profiles
    • Data elements are composed of their many independently obtained parts.

    * Simultaneous access allows background processes regardless of interface
    • Synchronization of mail, calendar and address book with remote servers
    • Mobile Sync
    • Allows the semantic environment infrastructure to access personal information
    • Archiving
    • Indexing
    • Out-of-process search

    * Multiprocess design
    • Crash Insulation
    • Large elements do not block the entire system
    • IPC Linking Allows Proprietary Components
    • Thin client installations can share components for greater scalability


    What does resource type independent mean? Groupware, IMAP, MS Exchange, vCard and everything else are separate resources, which are supported through various engines. Like 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 an order of magnitude easier.
    The overall design of Akonadi and its components is described in the API documentation . More information can be found on the Techbase project page .

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

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

    Also popular now: