Basic Thoughts

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