[Kde-pim] the kde-pim database internal structure.

[Kevin Krammer]

On Wednesday, 2012-10-31, Michaël Parchet wrote:

> There is no contacts and/or events table.
> 
> Where is storage thees data exactly ?
> 
> So wich the way akonadi server store and manage the data ?

As Andras already pointed out, Akonadi server deals with data on a generic 
level. The Akonadi clients, e.g. addressbook, calendar, communicate serialized 
data with an associated MIME type, so they can convert between the serialized 
form and the C++ data types.

Lets look at this on the example of contacts, starting the data source.

There are many forms contacts can be stored in, e.g. as single VCard files in a 
specific directory, as many vcard entries in a single vcard file, as an 
addressbook folder on a groupware server and so on.

For each of those backends which we want to support we need a way to access 
the data stored there. In an Akonadi system this is done by backend handlers 
called Akonadi Resources.

Each of those resources knows how to "talk" to its backend, e.g. the vcard file 
resource knows how to read and write vcard files and how to extract individual 
contacts entries from such files.

When the user (or an automated setup process) adds such a resource to the 
Akonadi setup, Akonadi server will ask the resource for the structure of its 
backend.
A simple resource like vcard file would be represented by only one contact 
folder, an addressbook server could have many.

Any end user program will see this folder when it asks Akonadi for e.g. all 
contact folders.

If the program wants to see the individual contacts, it will ask Akonadi 
server to list the folder contents.

Akonadi server will then check if it can answer that request from its cache, 
if not it will in turn as the resource to which the folder belongs.

The vcard resource in our example would answer by reading all entries in the 
vcard file and send that data to Akonadi server.
Akonadi server would then continue with the end user programs request and 
deliver the folder contents to it.

The Akonadi database doesn't need a contact table because it never needs to 
know that items in a specific folder (called Collections) is a contact. Only 
the resource and the end user program need to know.

This allows Akonadi server to work with any type of data without needing to be 
changed.

Any developer which needs support for a new type of data needs to create four 
things:

* a C++ data structure for holding the data, like KABC::Addressee for a 
contact

* a MIME type that identifies the data, like "text/directory" identifying 
contacts

* a class capable of converting instances of that class into a QByteArray and 
creating a new instance given such a QByteArray

* a resource capable of storing the data. usually the easiest way is to have 
one on-disk directory per folder and one file per item in such a folder 
(basically a one-to-one mapping of the on-disk data structure to the in-
Akonadi structure).

We have tutorials [1] for all those steps, unfortunately some are a bit 
outdated and do no longer reflect the best possible approach (but should still 
be applicable).

If you want to discuss any aspect in a more real time fashion, we also have an 
IRC chat channel on the irc.freenode.net network, called #akonadi

Cheers,
Kevin

[1] 
http://techbase.kde.org/Development/Tutorials#Personal_Information_Management_.28Akonadi.29
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20121101/b6e06bcc/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/