Zusammen mit KDE 4 will das PIM-Framework Akonadi zum Groupware-Standard werden. Das Ziel der Entwickler ist es, E-Mails und Kontakte zentral und mit einheitlichen Schnittstellen zu verwalten. Der Beitrag erläutert die Architektur und die wichtigsten Module.

Die Menge an Personal Messenger Information (PIM) nimmt stetig zu, aber auch die Anforderungen an die Verfügbarkeit von E-Mail, Kontakten oder Bookmarks wachsen. Auch bei einer Bahnfahrt durch unerschlossene Täler eines fernen Landes möchte der moderne Datennomade seine Mails lesen, sortieren und vorbereiten. Die KDE-Architekten erkannten daher zwei zentrale Probleme: mangelnde Wiederverwendung und eingeschränkte Remote-Fähigkeit. Mit den Mitteln des bisherigen KDE 3 waren beide Probleme nicht zu lösen.

So hat jede Anwendung bislang den Zugriff auf Datenquellen selbst umgesetzt. Manchmal haben gleich mehrere Programme konkurrierend die gleiche Aufgabe implementiert, etwa eine Kontaktverwaltung in KAddressbook und Kopete. Aus Sicht des Benutzers ist es ärgerlich, wenn sich Informationen nicht zwischen den Anwendungen austauschen lassen und deshalb Kopien der Daten angelegt werden. Liegen diese dann noch im Hauptspeicher, wird der Platz schnell knapp.

Das zweite Problem ist der Durchsatz, wenn eine Anwendung entfernte Datenquellen abfragt. Synchrone Übertragung von Daten führt oft zu Engpässen und die Anwendungsoberflächen aktualisierten sich nicht mehr zeitnah. Dazu kommt, dass entfernte Quellen oft große Datenmengen enthalten, deren direkte Übertragung das Problem noch verstärkt. Daten, die beispielsweise nur über Webdienste zugänglich sind, bleiben überdies insgesamt unerreichbar.

Prozessbeobachter

Im Zuge von KDE 4 planten die Architekten daher einen neuen Ansatz, den sie nach der ghanaischen Göttin der Gerechtigkeit Akonadi nannten. Eine zentrale Akonadi-Instanz pro KDE-Sitzung kümmert sich fortan um die Verwaltung aller PIM-Daten [1].

Akonadi ist eine Komponente, die als Server arbeitet und dem Entwickler zwei Arten von Bibliotheken anbietet: Klassen, um mit Akonadi selbst zu kommunizieren, und Darstellungskomponenten, um Benutzern PIM-Daten anzuzeigen. Die Benutzer profitieren dabei von fertigen Views, die verschiedene Anwendungen einfach verwenden können.

Zu Beginn einer KDE-Sitzung startet »akonadi_control« die Komponenten und wacht darüber, dass alle weiteren Prozesse auch laufen. Dazu ruft das Steuerungsprogramm die zentrale Komponente »akonadiserver« auf. Sie kümmert sich um die Verwaltung des Datenspeichers. Weitere Prozesse kümmern sich um den Zugriff auf Datenquellen (siehe Abbildung 1). Durch den Einsatz mehrerer Prozesse soll das Gesamtsystem robuster werden: Ein einzelner fehlerhafter Dienst zieht nicht mehr die komplette Komponente in den Abgrund.

Abbildung 1: Mehrere Prozesse bilden zusammen die Infrastruktur von Akonadi. Durch die asynchrone Struktur der Komponenten laufen einzelne Teile weiter, wenn langsame Netzwerkverbindungen den Nachschub blockieren.

Datenquellen aller Art

Im Datenspeicher legt Akonadi alle Informationen unabhängig davon ab, woher sie stammen. Datenquellen wie IMAP-Server oder Webmail-Dienste heißen Ressources. Jede Quelle wird dabei von einem eigenen Prozess verwaltet. Einzelne Prozesse für den Zugriff auf unterschiedliche Ressourcen zu verwenden war eine Kernidee, die zum Entwurf von Akonadi führte. Eine View reagiert so trotzdem noch auf den Benutzer, wenn im Hintergrund Daten geholt und aufbereitet werden – selbst wenn das Netzwerk einmal stockt. Datenzugriffe erfolgen daher immer asynchron, damit während des Lesens oder Schreibens das Benutzerinterface nicht blockiert.

Insgesamt will Akonadi hohe Bandbreite mit niedrigen Latenzzeiten erreichen, wenn es auf Ressourcen zugreift. Das gilt in besonderer Weise für entfernte Ressourcen wie IMAP-Server oder Webservices. Benutzer profitieren so davon, dass einerseits die Anwendungen besser bedienbar sind, und sie andererseits die Daten aus mehreren Quellen an einer zentralen Stelle verwalten und in Beziehung setzen können.

Kontakte lassen sich in lokalen Vcard-Dateien, einem Groupware-Server oder in einem Facebook-Account speichern. Alle Kontakte stehen dann beim Schreiben neuer Mails direkt zur Verfügung. Durch diesen einheitlichen Zugang zu allen PIM-Daten versprechen sich die Entwickler eine hohe Steigerung der Benutzerproduktivität.

Datenspeicher

Der Datenspeicher verwaltet sowohl Referenzen auf die eigentlichen Datenobjekte, die so genannten Items, kann sie aber auch komplett lokal speichern. Auch Mischformen sind möglich: So könnten die Nachrichten von E-Mails lokal liegen, die Attachments jedoch auf einem Server verbleiben, bis der Benutzer sie tatsächlich anfordert.

Zu diesem Zweck verwendet Akonadi eine relationale Datenbank. Aktuell unterstützt es SQLite und MySQL. Akonadi legt pro Benutzer transparent eine Datenbank auf einem lokalen Server an. Der Benutzer darf über eine Konfigurationseinstellung aber auch eine zentrale Datenbank anbinden.

Daten aller Art

Sollte die Verbindung zu den Datenquellen einmal nicht bestehen oder ist der Offline-Modus explizit gewählt, können Anwendungen trotzdem auf den Datenspeicher zugreifen und dort sogar Informationen verändern. Dies kommt besonders Nutzern von Laptops zugute. Baut sich die Datenverbindung erneut auf, gleicht Akonadi die Daten wieder ab. Insofern arbeitet der Datenspeicher von Akonadi wie ein Zwischenspeicher, der auch Konflikte mit den Ressourcenquellen erkennt und löst.

In seinem Cache vermag Akonadi jeden Typ von Daten zu speichern. Aus diesem Grunde ist jede Logik, die sich auf bestimmte Datentypen bezieht, vom restlichen Code klar getrennt. Auf diese Weise wollen die Entwickler künftig weitere Datentypen unterstützen. Damit grenzt sich Akonadi auch in seiner Architektur vom Evolution Data Server [4] ab. Akonadi ist flexibler hinsichtlich der zu speichernden Datentypen, um die sich Plugins kümmern. EDS hingegen konzentriert sich auf Kalender und Adressbücher. Die Architektur sieht jedoch Schnittstellen in beide Richtungen zwischen EDS und Akonadi vor.

Akonadi ist ein wesentlicher Baustein in der Infrastruktur von KDE 4. Aktuell arbeiten die Entwickler zwar noch an vielen Stellen, versichern aber, dass die Schnittstellen mittlerweile weitgehend stabil sind. In den letzten Monaten haben sie vornehmlich den Code optimiert und die Schnittstelle zur Benutzerschicht verbessert. Insbesondere haben sie sich jedoch mit dem Schreiben vieler nützlicher Ressourcen beschäftigt und so Akonadi beispielsweise an Exchange-Server, Delicious-Bookmarks und den Facebook-Dienst angebunden.

Ein weiter Weg

Die Release KDE 4.0 hat eine besondere Bedeutung für Entwickler, die außerhalb des KDE-PIM-Projekts eigene Erweiterungen anbieten wollen. Das KDE-PIM-Team will sich von nun an vorrangig darum kümmern, die diversen Anwendungen mit Akonadi-Support auszustatten. Dazu sind einige Änderungen am Code von Kontact & Co. notwendig. Das Team hofft jedoch, durch diese Arbeit viele Komponenten zu modularisieren und sich dadurch künftig viel Arbeit bei der Wartung der Applikationen zu ersparen. Anwender werden in den vollen Genuss von Akonadi also vorraussichtlich erst mit der Version KDE 4.1 gelangen.

Die Möglichkeiten von Akonadi sind daher zunächst vor allem für Entwickler interessant, die an mehreren Stellen die Angebote von Akonadi bereits jetzt nutzen können. Zwei Beispiele verdeutlichen, wie Anwendungsentwickler mit etwas Hintergrund in KDE- und QT-Entwicklung einerseits auf Datenelemente zugreifen und andererseits eigene Datenquellen erschließen, indem sie neue Ressourcen entwickeln.

Entwickler vor!

Um eigene Erweiterungen für Akonadi zu entwickeln, brauchen Programmierer mindestens die Headerdateien. Akonadi hängt hauptsächlich von QT ab, nur wenige Code-Anteile in den Ressource benötigen KDE-Libraries. Diese befinden sich jedoch in separierten Code-Abschnitten. Auf diese Weise sind beispielsweise auch Gnome-Entwickler eingeladen Akonadi zu nutzen.

In Zeiten aktiver Entwicklung ist das Subversion-Repository [3] die erste Adresse für den Code. Der Aufruf

svn co https://anonymous@anonsvn.kde.org/home/kde/trunk/KDE/kdepim/akonadi .

checkt den neuesten Entwicklungsstand in das aktuelle Verzeichnis aus. Entwickler benötigen in aller Regel zusätzlich noch die QT-Header, die »kdelib« und die »kdepimlib«, wenn sie alle angebotenen Ressourcen nutzen wollen. Eine weitere Konfiguration ist – bis auf die optionale Angabe einer Datenbank in der KDE-Konfigurationsdatei »akonadiserverrc« – nicht notwendig.

Architektur

Die Architektur von Akonadi [1] umfasst mehrere Konzepte, die Abbildung 2 zeigt. Das Projekt hat eine umfangreiche Dokumentation der Schnittstellen veröffentlicht, die bei der Entwicklung als Referenz dient [2]. Ein Beispiel verdeutlicht die ersten Schritte, die notwendig sind, um eine eigene Anwendung für Akonadi zu schreiben.

Abbildung 2: Die Architektur von Akonadi soll den Datenspeicher in die Lage versetzen, einerseits viele Datenquellen zu verwalten und andererseits auch vielen Applikationen einen einheitlichen Zugriff auf diese zu gewähren.

Zentrale Aufgabe von Akonadi ist das Speichern von Items in seinem Datenspeicher. Items dürfen jeden beliebigen Datentyp haben, der durch seinen Mime-Typ festgelegt ist. Auf diese Weise kann ein Item eine E-Mail-Nachricht, eine Vcard, ein Ical-Ereignis oder auch eine Bookmark sein.

Einige Items enthalten weitere Metadaten oder sind weiter strukturiert. Um solche Items zu bearbeiten, bietet Akonadi in der »libakonadi« die Klasse »Item« an. Ein Serializer-Plugin ist eine Voraussetzung dafür, dass Akonadi ein Item im Datenspeicher unterbringt. Das folgende Beispiel verdeutlicht, wie ein Entwickler diese Plugins schreibt.

Ein Item besteht aus seiner Payload, die die Nutzdaten enthält, einem String, der den Mime-Typ angibt und zwei Identifiern. Einer dient zur internen Verwaltung des Items im Datenspeicher, der andere enthält eine Referenz auf den Platz, auf dem Akonadi das Item in der entfernten Datenquelle wiederfindet. Listing 1 zeigt den klassischen Zugriff auf ein Item, im Beispiel auf eine Ical-Ressource, die Kalendereinträge aufnimmt.

01 Item item(ref);
02 cout << item.mimeType(); // "text/calendar"
03 IncidencePtr incidence =
04     item.payload<IncidencePtr>();

Strukturierte Elemente

Um Objekte als Payload zu übergeben, setzt man häufig Pointer ein. Damit diese Nutzdaten auch gültig sind, wenn Akonadi sie bearbeitet, ist der Entwickler dazu gezwungen, entweder wertbasierte Daten zu übergeben, beispielsweise durch den Code

item.setPayload<KBookmark>(bookmark)

oder alternativ einen gemeinsam genutzten Pointer zu verwenden. Akonadi benutzt dazu die Datenstrukturen aus der Boost-Bibliothek. Somit ist der »IncidencePtr« aus Listing 1 tatsächlich als

typedef boost::shared_ptr<KCal::Incidence> IncidencePtr;

vereinbart. Aus Sicht des Entwicklers verhält sich »IncidencePtr« exakt wie ein normaler Zeiger.

Die einzelnen Datensätze (Items) hält Akonadi grundsätzlich flach und ohne weitere Strukturierung im Datenspeicher. Weil jedoch viele Ressourcen ihre Datensätze hierarchisch organisieren, bietet Akonadi dies durch Verwendung der Klasse »Collection« ebenfalls an. Eine solche Sammlung enthält eine Liste von Identifiern, die sich auf Items beziehen. Tauchen einige Datensätze in mehreren Collections auf, sind leicht auch virtuelle Datensammlungen möglich. So stellt Akonadi beispielsweise Ergebnisse von Suchanfragen oder von Filterungen dar.

Verweise in die Ferne

Jede Collection unterstützt eine Menge von Mime-Typen. Sie nimmt nur Datensätze dieser Typen auf. Wenn eine Sammlung den Typ »inode/directory« akzeptiert, dann ist es möglich, Unterstrukturen zu bilden. Die Klasse »Collection« bietet dazu die statische Methode »collectionMimeType()« an. Listing 2 zeigt ein Beispiel, um eine Maildir-Ressource anzulegen.

01 Collection c;
02 c.setName(sub);
03 c.setRemoteId(path);
04 c.setParent(root);
05 const QStringList mimeTypes =
06    QStringList() << "message/rfc822"
07                  << Collection::collectionMimeType();
08 c.setContentTypes(mimeTypes);

Um ein Item zuzuordnen, verwendet Akonadi die Variable »ref«. Sie enthält ein Objekt des Typs »DataReference« und darin zwei Verweise. Einer zeigt auf den internen Akonadi-Identifier und wird verwendet, um das Element im Datenspeicher zu finden. Der zweite Verweis deutet auf den ursprünglichen Speicher in der Ressource. Strukturierte Sammlungen von Datensätzen speichern sowohl ihre »remoteId« als auch die »id« im »Collection«-Objekt.

Eine Ressource nutzt die »remoteId«, um den jeweiligen Datensatz zu finden. Beispielsweise setzt der Code

c.setRemoteId(path)

(aus Listing 2) einen Pfad als externe Referenz, da diese für die Datenquelle eindeutig bestimmbar ist. Entsprechendes muss für alle Datensätze gelten.

Einen einheitlichen Zugang zu verschiedenen Datenquellen definieren die Architekten von Akonadi als ein wichtiges Ziel. Dem trägt Rechnung, dass die Entwickler so genannte Ressources eingeführt haben, die spezifisch für die jeweiligen Datenquellen sind. Jede Ressource bietet einen einheitlichen Zugang zur Datenquelle, sodass Akonadi in der Lage ist, die einzelnen Elemente einheitlich in seinem Datenspeicher abzulegen. Um eine neue Ressource anzulegen, muss der Programmierer die Klasse »RessourceBase« ableiten.

Zugriff auf Datenquellen

Aus Nutzersicht ist es der Job von Akonadi, auf einfachem Wege Datenelemente aus dem Cache zu holen. Diese Aufgabe unterstützen Objekte der Klasse »ItemFetchJob«. Etwa alle Items einer durch »collectionId« beschriebenen Sammlung abzurufen, ist Sache dieses Code:

Collection c(collectionId);
ItemFetchJob* job = new ItemFetchJob(c);

Um ein einzelnes Datenelement anzufordern, für das eine Variable »ref« der Klasse »DataReference« vorliegt, genügt ein ähnliches Fragment:

DataReference ref(itemId, QString());
ItemFetchJob* job = new ItemFetchJob(ref);

Ist ein solcher Job erzeugt und hat der Kontrollfluss wieder die Event-Loop erreicht, kümmert sich der Job selbstständig um seine asynchrone Ausführung. Um das Ergebnis abzuholen, verbindet der Entwickler einen Slot mit dem Signal »result()«:

connect(job, SIGNAL(result(KJob*)),
        this, SLOT(listDone(KJob*)));

Listing 3 beschreibt, wie sich die Methode »listDone()« implementieren lässt. Akonadi sorgt dafür, den Slot aufzurufen, sobald der Job seine Suchanfrage beendet hat. Hierbei sei bedacht, dass dies unmittelbar geschieht, etwa wenn sich das Item bereits im Cache befindet, oder eine gewisse Zeit in Anspruch nimmt, wenn das System es erst von einer entfernten Datenquelle über eine langsame Leitung holen muss.

01 void MyClass::listDone( KJob* job )
02 {
03     if (job->error()) {
04         // Handle error
05     } else {
06         foreach (Item item, job->items()) {
07             // Do something with item
08         }
09     }
10 }

Das ist ein typisches Beispiel einer Kommunikation mit dem Datenspeicher von Akonadi: Zunächst erzeugt der Entwickler einen Job, verbindet einen Slot und implementiert diesen. Dadurch, dass er nicht mehr dafür verantwortlich ist, wie die Items gespeichert sind, ist der Code sehr übersichtlich.

Auf Jobsuche

Es ist nicht zwingend, für jeden Zugriff einen »ItemFetchJob« zu verwenden. Akonadi bietet alternativ einen abstrakterern Weg, um Datenelemente abzuholen. Dazu benutzt es die Modelle der Items. Entwickler haben die Wahl zwischen zwei Typen von Modellen: Generische Modelle können sie für jeden Mime-Typ verwenden, darüber hinaus existieren Typ-spezifische Modelle für einige Klassen wie das »MessageModel« für E-Mail-Nachrichten oder das »KABCModel« für Kontakte.

Solche Modelle erben von QTs »QAbstractItemModel« oder genauer von »Akonadi::ItemModel« für Items und von »Akonadi::CollectionModel« für Gruppen von Datenelementen. Daher arbeiten beide ähnlich. Um etwa eine View zu erzeugen, die die Elemente in einer »collectionId« darstellt, schreibt man:

mMessageModel = new MessageModel(this);
mView = new QTreeView(this);
mView-This>setModel(mMessageModel);
mMessageModel->setCollection( Collection(collectionId));

Der Code instanziiert das Modell und seine Präsentation (View) und verbindet beide. Der letzte Methodenaufruf, »setCollection()« weist das Modell dazu an, alle Elemente aus der Datensammlung zu lesen, die über »collectionId« definiert ist. Hinter den Kulissen geschieht dies zwar ebenfalls über den bereits beschriebenen Weg eines »ItemFetchJob«, aber das bekommt der Entwickler an dieser Stelle gar nicht mehr mit.

QT bietet Proxy-Modelle an, die Entwickler als eigene Ebene zwischen Modell und Präsentation einziehen können. Auf diese Weise haben sie die Möglichkeit, die Daten vor der Darstellung zu bearbeiten. Das macht Filter, Sortierungen oder auch Thread-Darstellungen der Interface-Komponente möglich.

Akonadi bietet ebenfalls einige Proxys an, darunter zum Beispiel das Proxy-Modell »MessageThreader«. Es arbeitet mit einem Agenten zusammen, der in einer Menge von E-Mail-Nachrichten nach Vater-Kind-Beziehungen sucht und die einzelnen Elemente daraufhin in einer Baumstruktur anordnet.

Serialisierung

Bevor sich Datenelemente lesen lassen, wollen sie überhaupt erst mal referenziert werden. Ein Item anlegen ist nicht kompliziert. Es erfordert zwei Schritte: Der zugehörige Mime-Typ muss zunächst ein Plugin zur Serialisierung anbieten. Wie bereits erwähnt, speichert Akonadi jeden Mime-Typ generisch in seinem Cache.

Um das zu erreichen, konvertiert Akonadi mit Hilfe von Serialisierungs-Plugins die Typ-spezifischen Daten in seine eigene Darstellung. Ein solches Plugin ist nicht schwer zu implementieren: Es erbt von »Akonadi::ItemSerializerPlugin« und muss die beiden virtuellen Methoden des API »serialize()« und »deserialize()« implementieren, um die rohen Daten in der Variablen »data« in die Datenstruktur von »item« umzuwandeln (oder umgekehrt):

bool deserialize(Item& item,
                 const QString& label,
                 QIODevice& data);
void serialize(const Item& item,
               const QString& label,
               QIODevice& data);

Items bestehen mitunter aus mehreren strukturierten Teilen, durch »label« separiert. Ist beispielsweise eine Mail zu serialisieren, erkennt das Plugin ihre drei Teile: den »PartBody«, den »PartHeader« und den »PartEnvelope«. Um Speicher zu sparen, legt das Item-Modell normalerweise nur den »PartEnvelope« im Cache ab und holt den größeren »PartBody« nur auf Anfrage. Für Nachrichten, Ical-Kalendereinträge und Vcards hat Akonadi schon fertige Plugins. Um eigene Item-Klassen zu unterstützen, lassen sich oft vorhandene Methoden der zugehörigen Mime-Typ-Objekte nutzen. Listing 4 und Listing 5 demonstrieren für ein »KBookmark«, wie sie die vorhandenen Methoden »fromMimeType()« und »populateMimeData()« heranziehen. In anderen Klassen gibt es oft »toString()«-Methoden, die dem Entwickler ebenfalls viel Arbeit abnehmen.

01 bool SerializerPluginBookmark::
02 deserialize(Item& item,
03             const QString& label,
04             QIODevice& data )
05 {
06     if (label != Item::PartBody)
07         return false;
08 
09     KBookmark bk;
10     QMimeData *mimeData = new QMimeData();
11      mimeData->setData(QString::
12            fromLatin1("application/x-xbel"),
13            data.readAll());
14     KBookmark::List bkl =
15       KBookmark::List::fromMimeData(mimeData);
16     delete mimeData;
17     if (!bkl.isEmpty())
18         item.setPayload<KBookmark>(bkl[0]);
19     return true;
20 }

01 void SerializerPluginBookmark::
02 serialize(const Item& item,
03           const QString& label,
04           QIODevice& data)
05 {
06    if (label != Item::PartBody)
07       return;
08    if (item.mimeType() != QString::
09            fromLatin1("application/x-xbel"))
10       return;
11 
12    KBookmark bk;
13    if (item.hasPayload())
14        bk = item.payload<KBookmark>();
15 
16    QMimeData *mimeData = new QMimeData();
17    bk.populateMimeData(mimeData);
18    QByteArray buffer = mimeData->data(
19     QString::fromLatin1("application/x-xbel"));
20    delete mimeData;
21    data.write(buffer);
22 }

Sicher verwahrt

Bei den eigenen Modellen kümmert sich Akonadi selbst darum, Datenelemente in den Cache zu übernehmen, wenn der User sie auf eine zugehörige View setzt. Das lässt sich ausnutzen, um ein Item im Datenspeicher abzulegen. Im Code muss der Entwickler es erzeugen und mit seinen Eigenschaften sowie Nutzdaten versehen. Bei einem bestehenden Bookmark »bk« sieht das so aus:

KBookmark bk;
Item item(DataReference(-1, bk.address()));
item.setMimeType("application/x-xbel");
item.setPayload<KBookmark>(bk);

Hier kommt wieder ein asynchroner Auftrag zum Einsatz: Ein Objekt der Klasse »ItemAppendJob« sorgt für die Speicherung und ruft einen Slot auf, um eventuelle Fehler prüfen zu können:

ItemAppendJob *job = new ItemAppendJob(item, collection);
connect(job, SIGNAL(result(KJob*)),
        this, SLOT(appendDone(KJob*)));

Entwickler dürfen also zwischen zwei Optionen wählen: Entweder stellen sie Aufgaben für Akonadi zusammen oder sie nutzen gleich die bereitgestellten Modelle. Gerade die letzte Variante ist bequem für Entwickler von Anwendungen. Sie verwenden bestehenden Code wieder, indem sie eine Subklasse von bestehenden Modellen bilden.

Ein neuer Speicher für Groupware-Daten

Das schlanke API und die Flexibilität seiner Konzepte markieren eine neue Generation eines Groupware-Speichers innerhalb von KDE. Die gewählten Ansätze erleichtern Entwicklern das Leben, da Akonadi gleichartige Arbeiten zentral in seinem Kern erledigt, statt sie in jeder Anwendung neu zu implementieren. Anwender werden hingegen von einer einheitlichen Behandlung ihrer unterschiedlichen Datenquellen profitieren.

Das Backend von Akonadi ist mit KDE 4 auf den Weg gebracht. Es bleibt abzuwarten, wie die einzelnen Projekte der KDE-Community die schlummernde Leistung unter der Haube in ihren Anwendungen einsetzen.