Akonadi Status

The state of Akonadi before the Osnabrück 5 meeting

Server

More or less implemented features:

• storage of items consisting of identifiers, mimetype, parent collection and an arbitrary (binary) data block
• IMAP-like data access interface supporting retrieval and modifications of both collections and PIM items
• D-Bus notification signals for changes to items or collections
• auto-generated low-level database access code
• uses transactions for all database write operations

Problems and missing features:

• cache mangement, expiring, filtering
• sqlite backend can't handle massive concurrent access, MySQL/Embedded looks like a interessting options but doesn't work either (might be a QSQL driver bug)
• communication with resources and search providers only works because of a huge hack which makes D-Bus calls from threads possible

Client Library

More or less implemented features:

• classes to represent collections and pim items
• job classes to retrieve and modify collection and pim items
• a self-updating collection tree model
• a self-updating flat pim item model
• a notification filter

Resources

We have a simple read-only iCal file resource. For more complex resource we probably need some more work on the resource API. Resources also have the same problem with async IPC complexity as search providers (see below).

Search Provider

Currently the biggest missing piece, there are still open questions about the design.

Search providers are supposed to provide type specific functionality, needed for the following features:

• initial creation of virtual folders (searching)
• updating existing virtual folders (matching a single item against all existing queries)
• generate type specific FETCH responses (eg. the mail header listing)

There are a couple of things making this complex:

• some resources (eg. IMAP, LDAP) provide search capabilities itself but not necessarily for all fields/operators
• some fields/operators are type specific, some are not; some are handled by the storage itself (eg. mimetype, collection), some by generic external tools (eg. fulltext search with strigi), some by the type specific search providers
• very complex fields (eg. event recurrence)

Since we probably don't want to write our own query evaluation engine, currently the best option seems to be to use Nepomuk for that. It is supposed to store the meta data of everything on the desktop, so putting PIM data in there is needed anyway. Its query language seems to have enough expressive power for our needs, but the performance has still to be evaluated. The Nepomuk developers are very interesseted in cooperating with us here.

There are also technical problems. First experiments at aKademy showed problems with async IPC complexity, the current solution of delayed D-Bus replies and multi-threading needs either to be simplified or completely hidden behind the search provider API.

Development Tools

There are three applications to access the storage backend:

• the akonadi command line client, but it is still missing several commands (some of them are available in the libakonadi tests)
• akonadiconsole contains a folder tree and complete log of network and D-Bus communication
• KMail via IMAP

Of course there is also netcat localhost 4444 and raw IMAP ;-)

General / Project Management

Given the current progress and our ambitious goals it seems unlikely that we will finish Akonadi and port all applications in time for KDE 4.0 (whenever that will be), especially when considering that Akonadi development also draws badly needed resources from KDE PIM development.

Therefore we might want to concentrate on getting only a subset of Akonadi ready and used for 4.0 (eg. just the storage, no searching), keeping KDE PIM features on the 3.5 level where possible and implement additional capabilities for the following 4.x releases.

[ Edit ]