Revision as of 02:55, 8 December 2010

Akonadi

Akonadi is complex, under-the-hood, and does not seem to have immediate benefits - this page can help communicate to end-users what Akonadi is good for. We recommend reading through the entire page.

What is Akonadi?

Akonadi is a framework that can understand and manipulate email, calendaring and contact information, or PIM (Personal Information Management) data, from different sources.

What can Akonadi do right now?

In short, not much. KDE PIM 4.4 is still in its infancy stage as far as harnessing Akonadi's power is concerned. Unfortunately the benefits of Akonadi will only be seen when more applications start using it. Luckily developers are well aware of this and applications, such as KDE PIM 4.5, are in due course to providing these benefits.

However at this point in time, Akonadi can:

Connect KDE Groupware apps with GMail and have your contacts imported.
Synchronise with Google Calendar.
Synchronise with Nokia's phone calendar.

Advantages Akonadi will provide in the future

KDE PIM 4.5 will be able to connect to most calendar servers out on the web, out of the box.
Seamless access to PIM data from any single application (email, calendar, todo, contacts, etc) from any source, including:
- Local file
- IMAP server (with support for push-IMAP)
- GMail/GCal
- Phone, mobile device or palm pilot
- Network file shares
- ... and really everything: Akonadi's modular structure make it easy for developers to write "connectors" to allow Akonadi to access data from any service.
Synchronize with other PIM applications and services easily.
Merge data into single "stream", such as data from Facebook, GMail, Hotmail, LinkedIn, and other social/PIM services to allow new innovative ways to interact with our data.
More flexibility to interact with PIM data, such as virtual folders based on SPARQL queries.
Perform all these functions continuously in the background instead of having to run multiple groupware applications. This increases the performance of applications as it removes the need for each individual application to load PIM data repeatedly.
Akonadi scales to your data as it supports pluggable backends (currently MySQL is implemented). For example, having a large amount of mail is no problem for Akonadi while other solutions will struggle with >50,000 messages. With modern storage you won't have to delete email anymore.
Performance improvements within applications, such as faster IMAP access, searching and tagging.
For developers, Akonadi is far easier to work with. While it might take some time to get it implemented in applications, it will make it easier to maintain, improve, and even fix bugs.

Possible problems faced by users

Packaging issues: packagers are not yet familiar and dependencies are new and sometimes still immature. In time, the out-of-the-box experience will get better.
Akonadi sometimes complains a bit too much, this is being worked on.
During migration it is possible some account settings are lost.
Memory: Virtuoso + MySQL costs more memory and more disk space.
KMail starts faster, but slower if Akonadi is not yet running.
On-server filtering for POP3 not yet implemented
Attachment loading on-demand not yet implemented
Server-side IMAP searching doesn't work, searching goes through Nepomuk
UID+ is required by the server, otherwise IMAP won't work (many servers support it, but don't report it working). Workarounds for GMX, GMail are already in.
We're not quite sure if Google IMAP works yet. (please test, Sebas)

Possible innovations brought by Akonadi

For example, applications like KOffice can’t access data from KDE PIM apps right now unless they are running. Akonadi runs as a background service so it’s data is always available. For example, you can have a docker in KOffice which attaches the current document to a new calendar event (currently in development). You can invoice app sending mails by itself instead of having to even start KMail. We could drag and drop groupware data streams to your Plasma Desktop and have them easily accessible there, live updating once something happens. Think email threads, chat logs, shared notes etc. The possibilities are endless.

We want these innovations to occur, and we'd appreciate ideas from the community on what to create. Add your own in the KDE Brainstorm. Here is one of the top-voted ideas in the KDE Brainstorm that has been brought to a reality via Akonadi:

The Migration towards an Akonadi based PIM Suite

The next big thing in terms of showcasing the benefits of Akonadi lies in the upcoming KDE PIM 4.5. This new version of Kontact is undergoing massive infrastructural changes. It is currently largely stable and feature-complete, and is assumed to be safe for standard usage. Even though data loss is highly unlikely and the remaining problems should only lie with weird and legacy setups, the KDE PIM team realises the risk of compatibility issues and is placing a large focus on the stability of the upcoming release. This will be done by releasing monthly betas - discouraged for the general public with vital data but necessary to ensure a stable final release.

During this migration period, the KDE PIM team would ensure that all possible migration scenarios are covered, as well as ensuring that rolling back to a traditional non-Akonadi Kontact (ie, PIM 4.4) is possible. Migration to and from Akonadi and non-Akonadi based PIM suites will be automated and with minimal data loss (at most, meta data such as flags will be lost). For extra security, it is recommended for testers to backup the $KDEHOME directory (usually ~/.kde). Obviously any and all bug reports should be reported.

Upcoming Features and Improvements

UI does not block anymore while filtering emails locally. This is the most hated KDE bug, and could previously not be fixed in a satisfying way. Akonadi's process separation makes it possible to fix this now.
Exchange support is within reach now (legwork done by the Samba team)
Fast virtual folders will come to full potential
Nepomuk features to link emails and contacts (and other semantic resources)
Clients for other platforms: KMail mobile, KMail on Windows
Fancy Plasma stuff (e.g. Lion Mail, Calendar integration is even already there)
Finer-grained native control over caching, e.g. attachments using Disconnected IMAP or per folder policies.

Information for Distro Packagers

Distros not willing to test the setup / packages should NOT ship
- mysql setup / apparmor
- prevent addressbook screwups
Nepomuk has to be on (no indexing needed), otherwise Kontact completion, groups won't work (this includes SC 4.4 as well).

Groupware Support

The following groupware servers can be expected to work with Akonadi-based Kontact components:

OpenXchange (not Exchange),
Scalix,
OpenGroupWare,
EGroupware,
TINE,
Google,
Zimbra
other GroupDav-based servers
Groupwise: use compatibility bridge
Any Kontact KResource plugin: the compatibility bridge can be used for everything that doesn't have an akonadi resource. This needs some configuration by user, though automatic migration should work, please report bugs if you encounter problems here.

FAQ

I don't like Akonadi. Can I not use Akonadi?
- In short, no. Akonadi is expected to become an integral part of KDE SC. Any problems you are facing now regarding Akonadi are a regretted and unfortunate stage in the introduction of any new technology. A better course of action would be to actively provide constructive debugging information to make a better KDE SC for everybody.
How/where does Akonadi store my data?
- Akonadi does NOT store user data. It caches it. The basic storage is still the traditional format, be it an online server (imap) or local files (ical calendar files). As for managing this, the "akonaditray" utility's configuration window can be used to manage resources, but this is not yet recommended for use by the uninformed.
Is Akonadi part of this whole semantic desktop thing?
- Akonadi works with Nepomuk, in that it feeds Nepomuk with certain information about it's data which will then be used to provide a semantic desktop.
Why not delay Akonadi integration?
- Delaying would mean maintaining several versions of the KDE PIM apps, thus wasting resources. Also, developers won't get to see Akonadi in action and have less incentive to start writing cool connectors, delaying the arrival of real benefits for the users even more. Finally, delaying would mean less testing, leading to more bugs and more delays.