Akonadi communication strategy

Akonadi is complex, low-level and does not seem to have immediate benefits - the memes on this page can help communicate what Akonadi is good for to counter the 'bloath' and 'empty promises' arguments.

What IS akonadi

Essentially, Akonadi is a framework that can understand and use email, calendaring and contact information from different sources. One benefit of this structure is that Akonadi can reduce system overheads - open up an address book once and share it across applications rather than each application opening up the same address book many times.

Another benefit is relatively easy coordination of data on different devices - making it easy to share, backup, and synchronize between your computer, phone, and the internet. For example, Akonadi can already synchronize with Nokia's phone calendars, and can access Gmail's contacts and Google Calendar, although those options are currently (KDE PIM 4.4) less evolved.

Benefits in one sentence

Akonadi lets you sync data data with many different online services, makes it easy for your applications to interact with your central store of events and contacts and reduces memory use by loading data only for use by many applications.

Memes

do cool things with Akonadi TODAY

You can connect KDE Groupware apps with Gmail, have your contacts imported (SC 4.4, still somewhat limited).
KDE PIM 4.5 will be able to connect to most calendar servers out on the web

What will be possible

access to data from everywhere, seamless
- You can access e-mails and calendar events from a local file, from an IMAP server, GMail/GCal, phone or palm pilot, or a network file share all in the same application.
Synchronize with anything.
- Synchronize this data with all kinds of applications and devices
merge data. Having data from Facebook, linked-in, Gmail, hotmail and notes all in one stream – new, innovative apps bringing all this information together can be written easily.
You won’t have to run any KDE Groupware app to have Akonadi work – it can sync and do it’s thing in the background, all the time.
Akonadi will make it easier to connect to services
- As Akonadi’s modular design makes it easier to write connectors for it (connectors gather data for the user from other services like Facebook or Gmail) there will be more of them. Already quite a few external developers are working on cool connectors. This includes syncing with phones and other devices!

It solves real world issues

EXAMPLES of real world issues solved by Akonadi
Accessing data from other applications
- 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 (in development). Or imagine an invoice app sending mails by itself instead of having to call upon KMail for this.
- another use would be to drag and drop groupware things to your desktop (plasma) and have them easily accessible there, live updating once something happens. Think email(threads), chat logs, shared notes etc
most issues are low in the stack, things developers have had to deal with. Akonadi is far easier to work with, and while it might take some time to get it implemented in the ‘old’ applications, it will make those apps easier to maintain and improve.
Performance. Currently, each KDE app which must access for example address book information must load KAddressbook. It can easily be loaded 5-6 times in memory. Akonadi makes this unnecessary, saving memory.
Scalability. Akonadi supports pluggable back ends (currently MySQL is implemented). Having huge numbers of mails is no problem for Akonadi – while other solutions will struggle when confronted with more than 50.000 mails… With modern storage you don’t have to delete email anymore so such numbers are less and less extreme.

issues it still might have that might bite you (price of progress)

Packaging issues galore: packagers are not yet familiar and dependencies are new and sometimes still immature. This creates issues. 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 settings like account settings are lost. However, the new KMail in KDE PIM 4.5 has a much improved account wizard which automatically configures most email accounts out there.

KDE PIM Messaging

Status as of July 2010

"normal usecases" are safe already
This is the old kmail on top of new infra

Kontact and the rest of the KDE PIM suite have been ported to the Akonadi groupware cache. The new Kontact is a straight forward port of Kontact as we know it from KDE SC 4.4, but it has undergone large infrastructural changes. The current status of the Akonadi-based KDE PIM can be described as: Kontact itself is largely stable and feature-complete, it is assumed to be safe for "normal" use-cases. The KDE PIM team would like to invite thourough testing now in order to realize a fully stable and well-working release of KDE PIM. This stable release is expected to happen in Q3 or Q4 2010, based on the results of the testing reports. When released, KDE PIM will be stable. Until the stable KDE PIM release based on Akonadi, monthly betas will be released. We would like to ask people to try using it and to get reports about problems. The KDE PIM team is fully committed to fixing issues that crop up. Especially important is the testing of migration scenarios at this stage. The focus is now on polishing the application and ironing out problems. Data loss at this point is highly unlikely. The main issues remaining are "weird" and "legacy" email setups and very large collections. "Normal use-cases" are safe at this point.

Migration

The KDE PIM team is paying special attention to the migration process from previous versions of Kontact and its applications. The migration strategy works in two ways:

Test and fix as many migration scenarios as possible
Make it easy to roll back to the traditional kontact (from 4.4)

As an extra safety-net for your data, backup your $KDEHOME, for example ~/.kde or ~/.kde4. Then install the Akonadi-based KMail, the migration process should start automatically. testing migration is especially important

=Rollback

In order to roll back, install the traditional Kontact, and use that:

data loss is very unlikely, issues are weird setups
the more email you have, the better
migration uses a *new* config, so rolling back is easy (status flags / tags between migrating and rolling back might be lost)
test data migration with weird, legacy setups

Please test the migration process and tell us your experience.

Distro Communication

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 - also in 4.4

Regressions

Performance & Resource usage: takes polishing (numbers vary wildly based on use-cases though)
Memory: Virtuoso + MySQL costs more memory, likely more disk space
KMail starts faster, but slower if Akonadi is not yet running
UID+ required, otherwise IMAP won't work (many servers support it, but don't report it working), workarounds for GMX, GMail are already in
Does Google IMAP work? (sebas: test)
On-server filtering for POP3 not yet implemented, no timeline (unlikely to have many users)
attachment loading on-demand not yet implemented (was only available in online IMAP anyway)
server-side IMAP searching doesn't work, searching goes through Nepomuk
http://thomasmcguire.wordpress.com/2010/05/14/akonadi-meeting-and-the-kde-sc-4-5-release/

Current Advantages over 'traditional' Kontact

More scalable (mega folders work better in kmail2 than in kmail1)
Syncing IMAP is magnitudes faster (there is still room for optimization)
PUSH IMAP works for the Inbox, support for arbitrary folders is coming up
full text search in emails is faster, and handled out of process (TODO: numbers)
Tag folders are as fast as others, don't block GUI
Virtual folders based on SPARQL queries from search dialog
see also: Thomas' presentation in Gran Canaria
Annotating, tagging emails, virtual folders based on these tags
Other apps start using Akonadi data (e.g. Plasma calendar)

Quality

- hard to fix crashes are easier to fix now (such as IMAP threading problems), gone completely, or less severe due to process-separation of the components

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.

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.
The whole PIM infrstructure is more robust
Going forward more other apps can access PIM data
Adding support for new resources is easy, adding support for more data types is easy
Exchange support is within reach now (legwork done by the Samba team)
Support for popular web services: Facebook data in Akonadi, LinkedIn contacts, ...
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 (TODO: link / screencast?), KMail Windows
Fancy Plasma stuff (e.g. Lion Mail, Calendar integration is even already there)
Native caching on a per folder cache policies, etc.
Finer-grained control over caching attachments using Disconnected IMAP, e.g. per folder

Questions questions

(what Akonadi is and is not)

It is important to note that 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).
Akonadi works with Nepomuk, in that it feeds Nepomuk with certain information about it's data.
Why not delay Akonadi integration? 3 main reasons:
- Delaying would mean maintaining several versions of the KDE PIM apps, wasting resources
- Delaying would mean developers don’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
- Delaying would mean it would get tested less, which in turn means even more delays