Commit 9e7dda94 authored by Volker Krause's avatar Volker Krause
Browse files

Recover and update some more of the ancient docs.

svn path=/trunk/KDE/kdepim/runtime/; revision=1188943
parent 633142ba
......@@ -11,8 +11,6 @@ blocks section below.
\section akonadi_overview Overview
- Design and Concepts
- \ref akonadi_design_basic
- \ref akonadi_design
- \ref akonadi_design_communication
- \ref akonadi_usage
- <a href="">Website</a>
......@@ -33,107 +31,6 @@ blocks section below.
\page akonadi_design_basic Basic Thoughts
To solve the \ref akonadi_history "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:
\li <em>Functionality is spread over different processes.</em><br>
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.
\li <em>Communication protocol is split into data and control channel.</em><br>
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.
\li <em>Separate logic from storage.</em><br>
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.
\li <em>Keep communication asynchronous.</em><br>
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 \ref akonadi_design
\page akonadi_design Akonadi Design
The main components are:
- \ref akonadi_design_libakonadi (libakonadi)
- \ref akonadi_design_server
- \ref akonadi_design_control
- \ref akonadi_design_agents (resources)
- \ref akonadi_design_storage
In the diagram below you can see a rough schematic view of Akonadi:
\image latex concept.eps "Akonadi Components" height=5cm
\image html concept.png "Akonadi Components"
For a more technical view go to \ref akonadi_overview_uml
\section akonadi_design_libakonadi 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.
\section akonadi_design_server 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.
\subsection akonadi_design_agents 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:
\li Autonomous Agents
\li Resources
Autonomous Agents are processes which only work on the cache of the Storage
and the user will (probably) never see them at work.
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.
\subsection akonadi_design_control 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:
\li Managing Resources
\li Notifications when the state of Resources have changed
The Control should be started in the startkde script and terminated at the end of the session.
\subsection akonadi_design_storage Storage
The Storage is part of the Akonadi Server and is responsible for managing the cache of %Akonadi items.
In other words, create the database schema and perform read/write operations on the database.
\page akonadi_design_communication Communication Schemas
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment