[dot] The Road to KDE 4: KDE PIM Libraries and Related Technologies

[Dot Stories]

URL: http://dot.kde.org/1182269390/

From: Troy Unrau <troy at kde.org>
Dept: are-you-sure-my-name-is-what-kontact-claims-it-is
Date: Tuesday 19/Jun/2007, @09:09

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
[http://pim.kde.org/] 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
[http://frinring.wordpress.com/2007/02/06/say-hi-to-%E1%83%AE%E1%83%90%E1%83%9A%E1%83%AE%E1%83%98/],
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, RSS2, 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...