Akonadi and PostgreSQL

As you might know, Akonadi uses a relational database system for storing meta information about the PIM data it manages. Since the first official release this has been MySQL because it provided all features we needed and was shipped with every modern Linux distribution. However there have always been users complaining about the usage of MySQL. They claim it is big, slow and has not the right license.... Leaving the FUD away, it can never be wrong to support multiple database systems, so during the last months we got several contributions from the community that allowed Akonadi to use PostgreSQL as its database. Unfortunately the patches only allowed to make use of an already running and properly configured server, which is something you can't expect from a user who just wants to read emails or looking up something in the address book.

So yesterday I took a couple of hours and checked whether it is possible to implement PostgreSQL support like it is done for MySQL, namely that Akonadi starts its own instance of the database server with a custom data directory and connects to it via unix domain sockets, so every user can have its own database server running. At the end of the day I had a working solution and after crosschecking with other PIM developers that my changes won't break anything I committed the patch this morning to trunk. If you want to test it, simply rebuild the Akonadi server from trunk, cleanup your Akonadi installation and configuration and change the content of $HOME/.config/akonadi/akonadiserverrc to

[%General]
Driver=QPSQL

[QPSQL]
StartServer=true

Now after a restart PostgreSQL should be used instead of MySQL. At this point I'd like to ask you, dear reader, for some help. The code that searches for the postgres executable has some paths predefined where the executable could be located. Unfortunately that differs from distribution to distribution. So can you tell me in the comments where the executable can be found in your distribution, please? Under Debian it is /usr/lib/postgresql/8.4/bin/, where is it under SuSE or Fedora?

Thanks for your help!

KAddressBook and Akonadi in KDE 4.4

On the last annual KDEPIM meeting there has been a lot of discussion how the further porting of the PIM applications (kmail, korganizer, kaddressbook etc.) shall proceed. The Akonadi server is stable and ready for day-to-day use and the client library is powerful enough to let a PIM application do most of its tasks. Because of the short time frame and the different complexity of code base, we decided to port KAddressBook to Akonadi for KDE 4.4 and port the other PIM applications for KDE 4.5. While the work on KAddressBook takes place in SVN trunk, the other work is done in a separated branch that will be merged back to trunk after the 4.4 release.

Working on the port of KAddressBook has been real fun, because I had the chance to throw away all the ugly, historically grown code and restart from scratch. On the one hand most of the storage management is handled by Akonadi now which reduces the code size enormously, on the other hand most basic functionality, like editing or viewing a contact, has been implemented as separated components, that are part of a library and therefor can now be used by other applications as well. So the whole code base of KAddressBook is much cleaner and well structured now. But also GUI wise I had the chance to improve the stale user interface from KAddressBook 3.5. The MacOS X user might recognize the overall appearance of the new KAddressBook UI, yes, I have to admit, the new design is inspired by the MacOS X address book ;)

Now I'll give you a small tour through the new KAddressBook with some nice screenies:

When you start the application you'll see a window like that one

On the left side you have the list of available address books, by default an address book 'Personal Contacts' will exists that contains all your contacts from your old KAddressBook installation (better said the ones from $HOME/.kde/share/apps/kabc/std.vcf). In the middle you see the list of all contacts that exists in the currently selected address book and its sub folders. On the right side the detailed information about the currently selected contact is shown. With the port to Akonadi, not only contacts are listed in the middle view, but also contact groups (TCGFKADL 'TheContactGroupsFormallyKnownAsDistributionLists'), so they are first class citizens now and integrate much better than in KDE 3.5.

The toolbar has been cleaned up and the user interface is as simple as possible. If the 3-pane look is still too complex for you, you can switch to the 'Simple UI Mode', than KAddressBook will look like the following:

Here you can quick search for a contact or contact group via the search line or iterate over the contacts with the 'Previous' and 'Next' buttons. This view should be enough for everybody who just wants to look up contacts quickly and seldom changes their data.

If you really want to add a new contact or change an existing one, you'll be using the new contact editor component, which is like already said available for every other application as well, so no strange dbus calls or exec('kaddressbook --new-contact') statements anymore.

In the 'Contact' tab you can enter the basic information of a person that you need to contact.


The 'Location' tab contains the addresses and coordinates of a person.


The 'Business' tab contains information that are useful for business contacts.


The 'Personal' tab contains personal information about a person.

In the future the editor will be extendable by plugins, so other applications can put there custom tabs there as well.

Let's go back to the address book and contacts view:

A right click on the address book view opens a menu where you can add, remove and modify the single address books (which in fact are Akonadi resources) and the address book folders. Yes, you can create folders and subfolders in your address book now to organize your contacts and in a later version we will also have virtual folders that allows you to group contacts by an arbitraty search query. A right click on the contacts view opens a similar menu where you can add, remove and modify contacts and contact groups.

If you right click on the header of the contacts view, a menu will appear where you can choose which columns shall be shown.

So these are the visual changes in KAddressBook, but under the hood there has been many changes as well. By default the contacts are stored now in a directory, each contact and contact group in its own file, so editing one contact will change only this file. The directory is located under $HOME/.local/share/contacts, so we can migrate later without having to care about $HOME/.kde3 vs. $HOME/.kde4 issues. Akonadi brings further features for free, for example offline mode with groupware servers, so you can do your changes offline and when you go online later on, the changes are transferred to the groupware server.

At the end of this blog only one warning, don't expect the current KAddressBook to be as feature rich as its previous version. This has been a complete rewrite and I integrated only the features that made really sense IMHO.

Pimp my Nepomuk

From time to time people show up on the #akonadi IRC channel and complain about the dependency of Akonadi on Nepomuk, because Nepomuk is so slow and takes 100% CPU when they start their desktop. The 'bad' news are, we won't drop the dependency on Nepomuk, because this is a technology no other desktop environment provides so far and it gives us all the nice features we want to have (from a Pimsters point of view ;))

So what's about the good news you might ask? Well, for those of you who have Nepomuk running with 100% CPU usage, we can make Nepomuk a lot faster!

When you execute the following command on a shell

qdbus org.kde.NepomukStorage /nepomukstorage usedSopranoBackend

you will see either 'redland' or 'semsame2' as output.

If your Nepomuk uses Sesame2 and it is still slow, your hardware must be really old (and I mean really, really old ;)), it works fine here on a Laptop with 500MHz and 256MB RAM...
For most of you, who see a high CPU usage of Nepomuk, however the Redland backend is used. So what is this backend thingy about? Nepomuk is a KDE specific high-level API for Soprano, which itself is a Qt-only storage solution for RDF (semantic) data. But Soprano doesn't implement the actual storage, it just forwards this task to its backends where currently two stable ones exists, the C++ based Redland and the Java based Sesame2. The reason for the high CPU usage is, that the Redland backend is much, much slower than the Sesame2 backend!

The careful reader might wonder now "Why is the C++ based backend slower than the Java based?" Isn't Java always slower than C++? Not in this case, the storage of RDF data and the querying involves many clever algorithms, so the C++ backend is bit here by the complexity theory. The Sesame2 backend in opposite has implemented many optimizations on the algorithm level and beats Redland performance wise.

So as strange as it sounds, to get a faster Nepomuk you have to install Java.

Yeah, I know, many people will scream now "WTF, why do I have to install this Java crap?!?", well, actually it could be that you have already installed it, OpenOffice for example brings along a JRE and to be honest, the reputation of Java is worse than the current implementations actually are. But back to pimping up Nepomuk...

If you use the KDE packages from a distribution, check whether there exists a package soprano-backend-sesame and install this one. If there is no such package available and all the other Soprano related packages do not contain a file
$KDEDIR/lib/soprano/libsoprano_sesame2backend.so bug your distributor to create them or do it yourself and publish them ;)

For the brave guys that use KDE compiled from sources, you need the following things:

• The Java development package (under Debian sun-java6-jdk)
• The Java runtime package (under Debian sun-java6-jre)

Now make sure that your compiler can find the development files by adjusting the LD_LIBRARY_PATH to contain the Java library directory:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jvm/java-6-sun/jre/lib/i386:/usr/lib/jvm/java-6-sun/jre/lib/i386/client/


(this are the needed paths under Debian, your paths might look a bit different).

Then just recompile Soprano from kdesupport (remember to clear the CMake cache before). CMake should output in the status report whether it has found the Java headers and libraries or not, if not, check your LD_LIBRARY_PATH variable again. If everything compiles fine, after a 'make install' you should have the file
$KDEDIR/lib/soprano/libsoprano_sesame2backend.so
available and after a restart of Nepomuk the qdbus command, I listed above, should return 'sesame2' now. And maybe you have already noticed, Nepomuk doesn't run with 100% CPU usage any more ;)

I hope this blog helps to reduce the prejudices against Nepomuk, because this software really rocks! Let's hope the distributors will finally ship sesame2 based Soprano packages!!!

W3C XML Schema validation with Qt

For all of you who want to make use of advanced XML processing with Qt and KDE, here is a preview story. Now we can maybe get rid of the libxml2 dependency at several places in KDE.