aKademy 2006: Akonadi - The KDE4 PIM Framework

This talk was held by Tobias Koenig.

He started with the following:
The 3 biggest mistakes made in human computer history:

• There will not be more then 10 computers in the world
• Nobody will need more than 640k of RAM
• Nobody will save more than 100 contacts in an adress book. (This one was made by me, 3 years ago)

In summary he explained the following points:
Why a new PIM Framework?
Akonadi (History, Concepts, Curent State, The Future)

Problems with old framework:
Bad Performance. (All data was loaded into memory. Thats good for local files, but when accessing groupware servers this takes the application down)
Synchronous Access. (Again, no problem for local files because this is fast anyway, but problematic for remote data)
Memory Consumption.
Missing Notifications. (The other applications did not know about changes in resources other than file resources)
Missing locking. (Very problematic when you want to synchronize data, because other processes could change the data while you where synchronizing)


Akonadi:
A general storage for PIM data that aims to solve the problems of kabc/kcal with a modular design for robustness and easy integration.

The first ideas of a PIM daemon came up at Osnabrück meeting 2005. Sample code for address book daemon was created, but was not welcomed very good by developers. But one year later: General agreement for PIM service at Osnabrück meeting 2006. - "Akonadi" was born

Akonadi is a service compromised of two processes:
The storage (interfaced with IMAP) and the Control process with a DBus interface

libakonadi wraps the service and imap connection and provides an easy to use interface. Ontop of that, some small wrapper libraries like libkabc and libkcal exist. The applications will use this
libraries directly.

The storage:

• Accessible via extended IMAP => high performance on data delivery (IMAP was invented for that, but until now only used for mail)
• Caches all PIM items of the resources (depending on policy, eg. groupware data is cached, local files likely not)
• Informs the control-process about changes
• Provides basic search features (IMAP)
• delegates extended search requests to SearchProviders

The resources:

• Applications wich synchronize data between the storage and an external data source (eg. groupware server or file) (This improves stability because a crashing resource does not take the whole system down)
• Asyncronous communication
• Profiles for grouping resources together (allows different views for normal viewing and synchronization)

The control-process

• Starts and monitors the Storage and resource process (resource processes are automatically restarted on crashes)
• Provides D-Bus API for managing resources and profiles
• Another library proxies this DBus-API into a library for application's use

The SearchProivders

• External applications which process more complex search queries
• One SearchProvider for every PIM item type
• Store search results in collections inside the Storage

Collections

• Virtual containers inside the Storage
• Contain PIM items/references
• Root collection "/"
• Every Resource provides at least one collection
• Easy to realize virtual folders
• /resource1
  /resource1/calendar
  /resource1/addressbook
  /resource2
  /search
  

Current State

• Storage (provides all needed IMAP commands), stores items in collections
• Control (lifetime managment for storage and resources already working, DBus API nearly completed)
• Resources (Simple iCaldenar file, dummy resource "Knut")

[Demo]

Todo

• Implementing SearchProviders
• Defining asynchronous client library (libakonady nearly done)
• Implementing full featured resources (remote and local file)
• Writing documentation

The future:
Goal: Components based PIM library where you create new applications just by gluing together components. Components meant as standalone views and editors of PIM data. Plasma applets for calendar and address book are also possible.

After that a little bit heated debate arose with the general question: Why not reuse existing technologies like LDAP or something else. Also concers where raised that the SearchProviders are seperate processes, and that would hinder performance.

Personal opinion: To say it the hard way: I was a little bit disapointed of this talk, and I'm also disappointed about akonadi. Don't misunderstand me: Its still a good concept, but i think some bits are missing still and they should consider to redesign some parts of it.