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 ;-)
Urgent tasks that need to be finished for the KDE 4.1 release (May 19th):
| Status | Item | Description | Contact |
|---|---|---|---|
| IN PROGRESS | Item size | Needed by Mailody | <thomas.mcguire@gmx.net> |
| TO DO | Payload serialization format versioning | see below | <Volker> |
| IN PROGRESS | Item streaming in ItemSync/ResourceBase | As discussed in Osnabrueck | <Tom> |
| DONE | API for additional item parts | As discussed in Osnabruck | <Volker/Tobias> |
| DONE | Infrastructure for showing additional dialogs from agents/resources | As discussed in Osnabrueck | <Tom> |
| IN PROGRESS | Allow to limit ItemFetchJob to current cache content | Prevents search index feeder agents from downloading all remote data | Volker <vkrause@kde.org> |
| DONE | Fix API for item/collection modifications | See Osnabrueck meeting notes for details | Volker <vkrause@kde.org> |
| TO DO | Error reporting | Akonadi::Job basically has only one error code: Unknown | <Tobias> |
| TO DO | Plugin Versioning | For serializer plugins, also check using Qt plugin stuff instead of the libkdepim plugin framework | [mailto: <>] |
| Status | Item | Description | Contact |
|---|---|---|---|
| DONE | Tray app | small app to control the server and have a something that can report errors | Toma <tomalbers@kde.nl> |
| IN PROGRESS | Akonadi Artwork | Icon for the tray app | Toma <tomalbers@kde.nl> |
| IN PROGRESS | Finish collection model/view | see below | <thomas.mcguire@gmx.net> |
| DONE | Backup support | Dump & Restore database contents, also useful when upgrading to a newer database version | <tomalbers@kde.nl> |
| IN PROGRESS | Collection statistics for sub-trees | Provide a CollectionStatus object covering the full sub-tree in the model, allowing accumulated unread counts etc. | <Thomas> |
| TO DO | Nepomuk integration | Generic Item tag/rate/comment, etc. | <Tom> |
| TO DO | Account creation wizard | as discussed in Berlin, see below | [mailto: <>] |
| TO DO | Sync collection tree after creating setting up a resource | see AgentInstanceCreateJob | [mailto: <>] |
| TO DO | Support standard commands for QUndo framework | [mailto: <>] | |
| TO DO | Conflict detection in resources | See Osnabrueck meeting notes for details | [mailto: <>] |
| IN PROGRESS | Action framework | see below | Volker <vkrause@kde.org> |
| TO DO | Solid integration | Switch online/offline state in ResourceBase automatically | [mailto: <>] |
| TO DO | Make unittests work without destroying the production database | [mailto: <>] | |
| TO DO | Fix API docs | The libakonadi move as well as the huge API changes following it broke lots of the docs technical and content-wise | [mailto: <>] |
Overview on the current state of support for various types:
| Type | Serializer | Multipart Support | Models | Views | Resources | Notes |
|---|---|---|---|---|---|---|
| yes | partial | MessageModel, MessageCollectionModel, threading proxy model | ? | maildir, IMAP | threading agent | |
| News | yes (1) | partial (1) | (1) | (1) | NNTP | |
| Contact | yes | no | ContactModel | - | vCard, facebook, KRes | |
| Events | yes | no | EventModel | - | iCal, KRes | |
| Notes | no | no | - | - | - | not started yet |
| Feeds | no | no | - | - | - | not started yet |
| Bookmarks | yes | no | - | - | local bookmarks, del.icio.us |
(1) see Email
| Status | Item | Description | Contact |
|---|---|---|---|
| TO DO | Extend Message Model | Add all required columns, save/restore layout, flag delegate, configurable columns, etc. | [mailto: <>] |
| TO DO | Share mail flag code | Standard actions, standard flag enum/constants, Nepomuk interaction | [mailto: <>] |
| TO DO | Extend ENVELOPE | Add more information to the envelope payload part in the serializer plugin, eg. trheading information is missing | [mailto: <>] |
| TO DO | Fix/finish threading | [mailto: <>] |
| Status | Item | Description | Contact |
|---|---|---|---|
| TO DO | Todo proxy model | See KOrganizers To-Do view | <Bruno?> |
| IN PROGRESS | Subtype identification | See discussion on kde-pim mailinglist | <Kevin?> |
| TO DO | Agenda view | KOrganizer agenda view based on Akonadi | <Bruno?> |
| TO DO | Month view | KOrganizer month view based on Akonadi | <Bruno?> |
| TO DO | Timeline view | KOrganizer timeline view based on Akonadi | [mailto: <>] |
| Status | Item | Description | Contact |
|---|---|---|---|
| IN PROGRESS | KResource Akonadi bridge | for applications using KCal or KABC | Kevin <kevin.krammer@gmx.at> |
| IN PROGRESS | Akonadi KResource bridge | for data accessed through KCal or KABC resources | Kevin <kevin.krammer@gmx.at> |
| TO DO | Expire Agent | [mailto: <>] | |
| TO DO | MBOX Resource | <Thomas> | |
| TO DO | Extend IMAP Resource | [mailto: <>] | |
| TO DO | POP3 Resource | <Thomas> | |
| TO DO | RSS Resource | [mailto: <>] | |
| TO DO | Filter Agent | [mailto: <>] | |
| TO DO | Search | [mailto: <>] | |
| TO DO | Filter Rule GUI | Used by filters and searches | [mailto: <>] |
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 |
| ? | ? | ? | ? | ? | Code in playground/pim | |
| del.icio.us | ? | ? | ? | yes | no | Code in playground/pim |
| KABC | no | yes | no | yes | yes | |
| KCal | no | yes | no | yes | yes |
(1) only full sync supported currently, need optimization (2) does not yet honor cache policy (3) still relies on QSettings for configuration and/or doesn't provide configuration over D-Bus (4) does not yet provide correct access control settings (5) only adding new items, not changing existing ones
Ideas/notes etc. on various open issues in Akonadi.
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.
State management: watch selection models of a collection and/or item model.
Use KXMLGUI for context menus in standard views to allow easy extensibility with custom actions.
Generic actions:
The list is definitely long enough to make this worthwhile.
Ideas/missing features/bugs of the collection model/view:
Notes on how to keep long-term protocol, source and binary compatibility.
Notes/ideas/complaints about the Akonadi::ResourceBase API:
Smaller stuff that should be fixed before the ABI freeze and is not yet listed above:
Notes on the resource configuration wizard discussion.
First review of the akonadi code reveals PGSQL Qt driver is already supported, but the code is not totally ready for it. Some first reading comments about where to patch for supporting PostgreSQL too:
mysql: SHOW INDEXES FROM %1
pgsql: SELECT c2.relname, i.indisprimary, i.indisunique, i.indisclustered, i.indisvalid, pg_catalog.pg_get_indexdef(i.indexrelid, 0, true), c2.reltablespace
FROM pg_catalog.pg_class c, pg_catalog.pg_class c2, pg_catalog.pg_index i
WHERE c.oid = '16713' AND c.oid = i.indrelid AND i.indexrelid = c2.oid
ORDER BY i.indisprimary DESC, i.indisunique DESC, c2.relname
relname | indisprimary | indisunique | indisclustered | indisvalid | pg_get_indexdef | reltablespace
--------------+--------------+-------------+----------------+------------+--------------------------------------------------------------+---------------
foo_pkey | t | t | f | t | CREATE UNIQUE INDEX foo_pkey ON foo USING btree (id) | 0
foo_time_key | f | t | f | t | CREATE UNIQUE INDEX foo_time_key ON foo USING btree ("time") | 0
(2 lignes)
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.
| Status | Item | Description | Contact |
|---|---|---|---|
| TO DO | Bodypart formatters | [mailto: <>] | |
| TO DO | Reader Window | [mailto: <>] | |
| TO DO | Composer: Editor | [mailto: <>] | |
| TO DO | Composer: Message Composer | [mailto: <>] | |
| TO DO | Composer: GUI Window | [mailto: <>] | |
| TO DO | Queue Manager for mailtransport | [mailto: <>] | |
| TO DO | Templates: Core | [mailto: <>] | |
| TO DO | Templates: GUI | [mailto: <>] | |
| TO DO | Port KMCommands | [mailto: <>] | |
| TO DO | Port away from KMMessage and KMFolder* everywhere it is left | [mailto: <>] | |
| TO DO | Migration application for index and other config | [mailto: <>] | |
| TO DO | Port MDNs | [mailto: <>] |
Sort of related so the stuff above but with a scope for all of KDE PIM and beyond.
| Status | Item | Description | Contact |
|---|---|---|---|
| TO DO | Share identity config GUI parts | eg. the signature configuration widget | [mailto: <>] |
| TO DO | Mailtransport Agent | Global shared outbox, central mail sending instance | [mailto: <>] |
| TO DO | Recently sent to support in mailtransport | related to above, based on Akonadi/Nepomuk | [mailto: <>] |
| TO DO | Composer engine | Shared stuff for KMail/KNode/Mailody: Crypto, editor, editor actions, attachment model, message assembly, etc. | [mailto: <>] |
~/.config/akonadi/
~/.local/share/akonadi/
So far only MySQL. There is some work on PostgreSQL support going on though.
We tried. Really. It can't handle the concurrent access very well.
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).
No. Akonadi starts its own local MySQL server. All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution).
Yes, it can. You find the corresponding settings in ~/.config/akonadi/akonadiserverrc.
No. There has to be one Akonadi server instance per user. However, it is possible to use a shared database server.
No. Akonadi is not a groupware server. It's a local cache only.
Distributions using Apparmor require you to run aa-complain mysqld with root privileges then reload apparmor.