Akonadi TODO

The following list contains the things which need to be done for Akonadi.

Note: The person noted in the "Contact" column is not necessarily the one implementing that feature, but the one who can tell you what to do and how to help, i.e. you can also contribute to those tasks ;-)

Core

4.1

Urgent tasks that need to be finished for the KDE 4.1 release (May 19th):

it would be great to have jobs which perform operations on several entities in one sitting (a use-case: mark all as read).

[mailto: <>]

TO DO

Batch job to retrieve a set of items from Akonadi

Those items don't belong to the same collection, rather they are located in different collections

[mailto: <>]

TO DO

CollectionFetchJob/ItemFetchJob should be able to retrieve entities by remote id/mimetype

This is problematic with change notifications, as they have to know about the filtering with the \Seen flag as well.
This type of filtering would be possible with full Nepomuk interface though. We don't want yet another query language here. The plan is to fix the nepomuk agent and use that as semi-public interface for now.

[mailto: <>]

TO DO

ResourceBase::collectionsRetrievalDone is missing

I'm working around by calling collectionsRetrievedIncremental() with empty collection lists

Store content data in files instead of the database, transfer filehandles instead of data to the client

[mailto: <>]

TO DO

Migration

Data and settings from pre-Akonadi times, see below

[mailto: <>]

TO DO

Remote Search

Delegating searches to resources, see below

[mailto: <>]

TO DO

Extended notifications

Item change notification do not yet include their source collections (real and virtual)

[mailto: <>]

TO DO

Alternative for Akonadi::ResourceBase

Not using the scheduler to avoid the serialization of operations, see RSS resource. (This will get very complicated. Maybe use a proxy ResourceBase for this, which is thread-pooled?)

[mailto: <>]

TO DO

Collection parameter for Monitor::itemChanged() and Monitor::itemRemoved()

If the item resides in several collections (normal + virtual collections) then emit those signals for each collection. Adding this would mean changing it in many places (Monitor, Observer, ...), this is lots of work but probably the right thing to do.
Related to virtual collections, since with them, items can be in multiple collections. Better wait until the Nepomuk stuff is finished?

Resource status overview (this should list all resources existing in KDE3 or already under development for Akonadi):

Resource

Retrieve Collections

Retrieve Items

Change Collections

Change Items

Configuration

Notes

iCal

yes (4)

yes (1) (2)

no

yes (5)

yes

does not yet watch for file changes

vCard

yes (4)

yes (1) (2)

no

?

yes

does not yet watch for file changes

maildir

yes (1) (4)

yes (1) (2)

?

?

yes

mbox

no

no

no

no

no

not started yet, code exists in KMail

IMAP

yes (1) (4)?

yes (1) (2)

no

no

no

code exists in kio_imap4 and Mailody, support for extensions: quota, ACL, annotations missing, what about Kolab and Scalix?

POP3

no

no

no

no

no

not started yet,code exists in kio_pop3

NNTP

yes (4)

yes (2)

n/a

n/a

yes

Needs support for local collection names and collection hierarchy

Local Bookmarks

?

?

?

?

(3)

Code in akonadi/resources

OpenChange

?

?

?

?

?

Code in akonadi/resources

Facebook

?

?

?

?

?

Code in playground/pim

del.icio.us

?

?

?

yes

no

Code in playground/pim

KABC

yes(6)

yes

no

yes

yes

KCal

yes(6)

yes

yes(7)

yes

yes

only full sync supported currently, need optimization

does not yet honor cache policy

still relies on QSettings for configuration and/or doesn't provide configuration over D-Bus

does not yet provide correct access control settings

only adding new items, not changing existing ones

availability of child collections depend on whether the KResource plugin has subresources

child collections can be added or removed if the KCal plugin can have subresources

Akonadi Braindump

Ideas/notes etc. on various open issues in Akonadi.

Akonadi Standard Actions

Idea: Have something like KStandardAction for Akonadi that not only includes the representation of the action but also its state management and the actual operations. Like libakonadi that should be splitted into a generic, type-independent part and be extensible for type-specific actions. This will enable code sharing among many applications and guarantee consistent actions everywhere.

Deployment issues

Multiple access: Should multiple Akonadi instances' mysqlds access a single set of data files the mysql will likely corrupt the data. This can happen in any NFS+YP installation where users can log onto any machine and access shared homes. MySQL relies on filesystem locking to prevent multiple access. MySQL multiple instance docu.

AppArmor: Distros' AppArmor profiles prevent MySQL from writing outside its defined data directory (usually /var/lib/mysql). This is a problem at least with *buntu and openSUSE. These will need to be adapted. It is possible to daisy-chain profiles so that MySQL started by Akonadi receives a different profile to MySQL running standalone. An empty profile has all rights. Another possibility is to adapt the general MySQL profile so it can write to ${XDG_DATA_HOME}/akonadi(usually ${HOME/}.local/share/akonadi). Both support for profile chaining and ${HOME} may depend on the version of AppArmor installed. What about SELinux?

Backup: MySQL data files should not be backed up without telling the mysqld process, otherwise a corrupt backup will be made. LOCK TABLES and FLUSH TABLES at the least. A dump can be made or mysqlhotbackup may be used in some circumstances. We should consider sysadmins' backup techniques when planning/promoting Akonadi, as a simple rsync cronjob with running Akonadi will not work. MySQL backup advice.

akonadi/server/src/storage/datastore.cpp

line 700, qint64 DataStore::highestPimItemId() const, seems wrong for a concurrent program (SELECT MAX(col) FROM table; is not reliable if another thread is inserting at the same time) : check the callers

KMail Breakdown Plan

The current plan is to put some parts of KMail into a stand-alone
library, independent of KMail. This increases code reuse (for example, the message composer could be shared with Mailody) and makes the code a lot easier to maintain and to port to Akonadi.

Which DBMS does Akonadi use?

So far only MySQL. There is some work on PostgreSQL support going on though. Basically, every database that is supported by QtSQL can be used, requiring minimal changes in the code at most. However, not all of them provide the features needed by Akonadi (see next two questions).

Why not use sqlite?

We tried. Really. It can't handle the concurrent access very well, in the best case this means very slow operations, but we've also seen deadlocks and failing transactions. Once that's fixed in sqlite, adjusting Akonadi to use it again instead of MySQL is no problem.

Why not use MySQL/Embedded?

We tried that as well, there are two reasons for not using it: No support for the InnoDB engine (which we need for transaction support) and poor availability (only OpenSUSE provided usable packages, needed a patched QSQL driver).

Do I need a running MySQL server?

No. Akonadi starts its own local MySQL server (unless configured otherwise, see next question). All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution).

Can Akonadi use a normal MySQL server running on my system?

Yes, it can. You find the corresponding settings in ~/.config/akonadi/akonadiserverrc.

I don't like a database server because of backups/running on NFS/etc.

See section "Deployment Issues" above, we are aware of that and working on it. Some of these, like backup/restore are already implemented. But please be aware that most of this issues also existed before (eg. with KMail's custom binary indexes).

Can a single Akonadi instance be used by multiple users?

No. There has to be one Akonadi server instance per user. However, it is possible to use a shared database server.

Can I access the Akonadi server on a remote machine?

No. Akonadi is not a groupware server. It's a local cache only.

What's the difference to EDS?

EDS is limited to contacts and calendar data, Akonadi is type-independent. Especially, Akonadi is designed to also handle high-volume data such as email. Akonadi and EDS also differ largely in their access protocol on the technical level (Corba/D-Bus vs. local socket with IMAP-like protocol/D-Bus) as well as one the protocol level (type specific vs. generic).

How do I create a collection?

From the developers point of view, there is Akonadi::CollectionCreateJob for that, from the users point of view, most applications allow that, eg. Mailody or akonadiconsole.

However, there is one limitation: Top-level collections can only be created by resources, not by normal applications. The reason for that is that every object (collection or item) is supposed to have an owning resource, that is a resource that is responsible for storing and retrieving that object. There is an ongoing discussion to remove this restriction though.

So, if you want to create a collection eg. for testing purposes, add a resource first. Most Akonadi applications offer an option to do that, a module for KControl is planned as well.

How do I disable automatic migration from KDE's traditional framework?

The migration tool is controlled by standard KDE configuration file called kres-migratorrc.

Distributors or system administrators wanting to disable the automatism will probably want to that globally, e.g. by editing the installed default configuration file, or by using KDE's configuration hierachy and using a profile config between that and the user level.

The quickest way to deactivate it for one user account only is to use KDE's kwriteconfig tool to set the respective configration value with a simple copy&paste of the following command:

Please note that at some point KDE applications such as Kontact, KOrganizer, KMail, KAddressBook will be using Akonadi directly, at which point migration either has to be enabled or performed manually.

What is the relation between Akonadi and OpenSync?

Akonadi and OpenSync focus on different aspects and complement each other. Akonadi provides a unified way to access PIM data for applications and a framework to implement powerful connectors to varies data sources. OpenSync focus is on syncing two sets of PIM data.

An Akonadi plugin for OpenSync is currently under development, allowing to sync PIM data available through Akonadi with any other system supported by OpenSync, especially mobile phones.