The Road to KDE 4: KDE PIM Libraries and Related Technologies

KDE has a number of sub-projects that have blossomed into enormous projects of their own. A number of them, such as KOffice, or KDE-Edu get a lot of press in the open source world, while the KDE PIM project has been quietly gaining corporate acceptance as a suitable enterprise suite. Today's feature are the libraries that power the KDE PIM project, and specifically, what changes have taken place since KDE 3.5.x, wherein the KDE PIM project is one of the most successful and stable components of KDE. Read on for more details.

The KDE PIM (Personal Information Management) team has stability among their primary goals. As a result, the changes to KDE PIM are not as flashy as some of the other technologies going into the KDE 4 applications, and in fact, many of the KDE 4 PIM applications will initially appear to be direct ports of their KDE 3.x counterparts. However, much of the focus at this point has been future-proofing technologies, since the opportunity to introduce new APIs and break old ones does not come around very often. To that end, a number of new libraries have been developed, and old ones reworked.

Akonadi

Akonadi is KDE's new storage backend, named after the oracle goddess of justice in Ghana. It's not really a backend, rather a generic backend API, which can have any number of real storage solutions implemented, from flat files to complex groupware servers. It supports caching, so offline modes should be implicitly available regardless of how the data is actually stored and retrieved.

It is considered to be the replacement for the existing resources framework in KDE, but is also extensible to data types that were not available to KDE 3.x. For example, the Akonadi framework will obviously be useful for email, contacts, and calendars just as the old frameworks were, however it can be extended to a number of other useful types as well. Volker Krause, a prominent developer of Akonadi, suggests that Instant Messaging (IM) logs may be useful to support, as it could just as easily query your hard disk for stored logs as it could retrieve the logs from the browser-based GoogleTalk. Of course, being cached, it would still be able to query these logs without going directly through GoogleMail every time.

Additionally, Volker writes that "Akonadi uses a completely language/toolkit independent interface, based on D-Bus and an IMAP-like protocol, making it possible to use it from non-KDE software without linking to any KDE/Qt libs." Which means that you can write lightweight programs that take advantage of Akonadi without having to link to the whole set of KDE and Qt libraries. This D-Bus control should also make access to the data stored in Akonadi trivial for writing scripts for automation and similar tasks.

That said, there are parts of Akonadi that integrate very well with Qt and KDE. In particular, it has support for very smart copy/paste and drag/drop for applications that want to deal with data stored in Akonadi. If you drag the name of a contact, for example, into a text file, you'll get their name since that's the only format that a text file can understand. If you drag it into a calendar, the calendar can easily recognize that it is accepting a drop of a contact, and could conceivably ask you if you'd like to make an appointment with this contact, etc. The libraries support this level of integration, but it may take a while for the applications to take full advantage of it.

For storage, Akonadi is only limited to those plugins that have already been programmed. The default will be to store most data in flat files, much as it is done now, but handle things like the relationships between the data using an SQL database backend or similar. In the past, KMail, KNode, etc. each had to do their own implementations of the data relationships, often in an application-specific binary format. This data will now be able to be shared more easily. Additionally, Akonadi provides "persistent unique identifiers for every item as well as change notifications" which are required in order to implement effective metadata searching, such as that being provided by the NEPOMUK-KDE integration. The metadata indexing isn't done by Akonadi itself, but rather, it is written in such as way that it becomes trivial to hook an existing system into whatever storage backend is active.

Since Akonadi itself is "type neutral", additional libraries have to be implemented for each type supported. In some cases, these libraries have been rewritten from existing KDE 3.x libraries (contacts, for example), and in other cases, the existing libraries should work with a little coaxing (KCal, KMIME, etc.).

However, I will once again stress that while this library will be shipped with KDE 4.0, the KDE PIM applications will not necessarily have been fully adapted to take advantage of the new functionality. At this point it is simply laying the groundwork and ensuring that the API is complete so that it doesn't break between future KDE 4.x versions. I would consider the development of Akonadi to be the biggest change taking place in the KDE PIM circles, and probably the most important for the long term forward progress of KDE PIM.

Khalkhi

Khalkhi is designed to be the new contacts framework for KDE 4, which happens to be the Georgian word for "people" (it is pronounced in a way that I cannot properly describe using English, but Friedrich has attempted to do just that in his blog, which also happens to be a nice introduction to the technology). It features a number of new things that the existing KABC cannot do, for example:

• It has a concept of groups, and relationships between people. People can belong to groups. Groups can belong to other groups. NEPOMUK may find the relationships between people to be useful as part of its searching and indexing.
• Share properties between groups/persons. You can change the contact info for many people at once if you define them as sharing a mailing address, for example.
• Plugin-based property types. You are no longer restricted only to the contact information that is hard-coded into KABC, such as email addresses. You can add contact information for new types simply by adding a plugin. For example, one could add fields corresponding to the user accounts at a number of online websites (such as Flickr photo sharing, or Last.fm music profiles) which would be automatically available to all programs using contacts.
• Incremental Updates. In KABC, a program had to reload the entire contact list any time there was a change, which becomes inefficient especially for large contact lists. Khalkhi can do these changes incrementally, without reloading.

Khalkhi is a little behind the other libraries as far as integration goes, and will probably not be visible before KDE 4.1. If you are interested in this sort of technology, you can contact Friedrich Kossebau directly, or drop into the #kontact channel on IRC and lend a hand.

KitchenSync

No name change, though pretty much a new project. According to Cornelius Schumacher, "It's called KitchenSync. It doesn't share more than the name with the KDE 3 KitchenSync though."

KitchenSync used to be KDE's syncing library and GUI, which implemented ways to get data from various PDA's and similar devices. KitchenSync is now a framework that sits on top of the OpenSync infrastructure complete with ported UI from the old program. Plugins should be much more stable and maintained now that they live in the OpenSync project. This will benefit KDE and other projects in much the same way as the abstraction of the SANE libs did for scanners.

KDE PIM developer Tobias Koenig says that "now the plugins [are] coming from the OpenSync project, so we have a broader and better tested set of plugins. The only plugin which needs porting to Akonadi is the OpenSync kdepim-sync plugin. However that will be done [shortly]". OpenSync is GUI independent, and simply deals with the communications to and from the device, which means we still need dialogs to configure this connection. Fortunately, he writes: "To make the implementation easier, a current [Google Summer of Code] project is about creating abstract descriptions (XSD) for the plugin configuration settings, so that configuration dialogs can be created automatically."

KitchenSync is already functioning quite well for KDE 4, and with a little polish, should be ready for 4.0.

Mail Transport

This is a new library for KDE 4.0. It is essentially an integration library that shares email settings in a far superior way to KDE 3.x. In KDE 3.x, you had to set up your mail account in every application separately. Volker Krause describes it as: "A small library which takes care of configuring and sending mails. The really nice thing here is that it is used by KMail, KNode and Mailody and allows them to share the same settings (including live updates if you change them in one app, etc.). Something similar is planned for identities (might not be ready for KDE 4.0 though)."

This library should allow easier integration of email services into other applications, without each application having to be aware of how the email is being sent. It will show up in existing KDE applications for KDE 4.0, but the real strength here is for third party applications.

Syndication

This new library takes the hassle out of handling a number of syndicated news formats, and presents an API for applications to get and use news feeds. It currently has support for the commonly used formats, Atom, RSS and RDF. Adding additional formats in the future are not especially difficult, and programs using syndication would automatically be aware of them. Many of the PIM developers consider this to be one of the most exciting additions to kdepimlibs for KDE 4.0.

The Wrap Up

There is a lot of new work going into the PIM Libraries for KDE 4.x, some of which won't be ready in time for 4.0. Expect that many of the KDE PIM applications are not yet updated for the new libraries when KDE 4.0 is released, but will still be using ported versions of the 3.x libraries. As I mentioned before, one of the main goals for KDE PIM is stability, and by using the older libraries for the 4.0 release, you can be assured that you will at least have a working PIM environment that is functionally equivalent to the 3.x applications. However, expect new and exciting things to come from KDE PIM beyond KDE 4.0. Also, as the KDE 4.0 release draws nearer, expect an article focusing on the PIM applications.

Lastly, I will leave you folks with a bit of gossip to chew on. This will be the last Road to KDE 4 article fully hosted by the dot as I am moving it to a new source where it will give KDE wider exposure within the tech world. I cannot reveal all of the details yet, but I will confirm that these articles will still be linked from the Dot, which is good since it has a fully open, unmoderated comments forum, and many of these articles have generated a great deal of constructive feedback for the developers. The next article will be on either Krita or Kate (haven't decided which one will go first).

Until next time...