akonadi
To solve the
problems of KDE 3 and make
Akonadi ready for the requirements of the KDE 4 release cycle, some considerations had been made which had a deep influence on the design:
- Functionality is spread over different processes.
This separation has the big advantage that if one process crashes because of a programming error it doesn't affect the other components. That results in robustness of the whole system. A disadvantage might be that there is an additional overhead due to inter-process communication.
- Communication protocol is split into data and control channel.
When doing communication between processes you have to differentiate between the type of data that is being transferred. For a large amount of data a high-performance protocol should be used and for control data a low-latency protocol. Matching both requirements in one protocol is mostly impossible and hard to achieve with currently available software.
- Separate logic from storage.
By separating the logic from the storage, the storage can be used to store data of any type. In this case, the storage is a kind of service, which is available for other components of the system. The logic is located in separated components and so 3rd-party developers can extend the system by providing their own components.
- Keep communication asynchronous.
To allow a non-blocking GUI, all the communication with the back-end and within the back-end itself must be asynchronous. You can easily provide a synchronous convenience for the application developer; the back-end, however, must communicate asynchronously.
Keep these considerations in mind when you read
Akonadi Design
KDE 4.1 API Reference 