KDE PIM/Akonadi
< KDE PIM
Akonadi TODO
The following list contains the things which need to be done for Akonadi.
Core
| Status | Item | Description | Contact |
|---|---|---|---|
| DONE | Cache policies | As discussed in Osnabrueck | Volker <[email protected]> |
| DONE | Agent configuration | As discussed in Osnabrueck | Volker <[email protected]> |
| TO DO | Item size | Needed by Mailody | [mailto: <>] |
| TO DO | Item streaming in ItemSync/ResourceBase | As discussed in Osnabrueck | [mailto: <>] |
| IN PROGRESS | API for additional item parts | As discussed in Osnabruck | <Volker/Tobias> |
| IN PROGRESS | Infrastructure for showing additional dialogs from agents/resources | As discussed in Osnabrueck | <Tom> |
| TO DO | Allow to limit ItemFetchJob to current cache content | Prevents search index feeder agents from downloading all remote data | [mailto: <>] |
| TO DO | Conflict detection in resources | See Osnabrueck meeting notes for details | [mailto: <>] |
| IN PROGRESS | Fix API for item/collection modifications | See Osnabrueck meeting notes for details | <Volker> |
| DONE | Remove DataReference | Fold back into Item | Tobias <[email protected]> |
| TO DO | Support standard commands for QUndo framework | [mailto: <>] | |
| IN PROGRESS | Action framework | see below | Volker <[email protected]> |
| IN PROGRESS | Tray app | small app to control the server and have a something that can report errors | Toma <[email protected]> |
| DONE | Server-side copy | for items and collections | Volker <[email protected]> |
| TO DO | Finish collection model/view | see below | [mailto: <>] |
| TO DO | Solid integration | Switch online/offline state in ResourceBase automatically | [mailto: <>] |
| TO DO | Hierarchical dptrs | Use for all job classes, check where else this makes sense | Tobias <[email protected]> |
| TO DO | Make unittests work without destroying the production database | [mailto: <>] | |
| TO DO | Backup support | Dump & Restore database contents, also useful when upgrading to a newer database version | [mailto: <>] |
| TO DO | Error reporting | Akonadi::Job basically has only one error code: Unknown | [mailto: <>] |
| 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> |
| IN PROGRESS | Use 64bit ids | Otherwise we'll run out of identifiers in 6.8 years, and that's just thanks to the ItemAppendJob speed limit ;-) | Tobias <[email protected]> |
Supported Types
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
Mail specific extensions
| Status | Item | Description | Contact |
|---|---|---|---|
| TO DO | Extend model/view stuff for mails | [mailto: <>] |
Event/Todo/Journal specific extensions
| 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: <>] |
Resources, Agents and others
| Status | Item | Description | Contact |
|---|---|---|---|
| IN PROGRESS | KResource Akonadi bridge | for applications using KCal or KABC | Kevin <[email protected]> |
| IN PROGRESS | Akonadi KResource bridge | for data accessed through KCal or KABC resources | Kevin <[email protected]> |
| 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
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.
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:
- new collection [done]
- new virtual collection
- delete collection [done for single selection]
- copy collection [done]
- cut collection
- paste collection [done]
- synchronize collection [done for single selection]
- synchronize resource
- synchronize everything
- show collection properties dialog [done]
- delete item(s) [done]
- copy item(s) [done]
- cut item(s)
- paste item(s) [done]
- paste native data
- tag item(s)
- comment item
- rate item(s)
- configure resource
- add resource? (would need a type parameter, etc.)
- delete resource
- manage local subscriptions [done]
- move to submenu
- copy to submenu
The list is definitely long enough to make this worthwhile.
Collection Model / Collection View
Ideas/missing features/bugs of the collection model/view:
- Enable/disable status columns
- Show status after the name (see KMail)
- Size column
- Save/restore layout
- Custom collection icons (see KMail, also needed for resource defined special folders (eg. Inbox)
- Status tooltips (see KMail in 3.5.9)
- Quick search
- Favorite folder view as proxy model on top of the normal collection model (FlatCollectionProxyModel might be helpful for there)
- Accumulated statistics (unread, total, size)
Compatibility
Notes on how to keep long-term protocol, source and binary compatibility.
- Detect server version in Akonadi::Session, might be useful in case of protocol extensions/changes
- What about database server version updates?
- Versioning or any other kind of serialization format meta data, we'll need that in case of changes in serialization formats (see eg. Robert's compression patch where this is needed)
- We currently use 32 bit ids, probably hard to change later on, is that enough?
- Plugin versioning
Resource API issues
Notes/ideas/complaints about the Akonadi::ResourceBase API:
- Extremely error prone:
- Scheduler dead-locks when a requested operation is not correctly announced as finished, esp. a problem in error cases.
- Using the result methods multiple times or when not requested asserts
- Item streaming is missing, requiring all data to be in memory at once
- Non-incremental updates need to know the results of ItemSync to not have to provide all data, even for already existing/unchanged items.
API / BC issues
Smaller stuff that should be fixed before the ABI freeze and is not yet listed above:
- Hierarchical dptrs where useful
- Cleanup the D-Bus format used by NotificationMessage
- No mentioning of "IMAP" in the public API, we are not using IMAP
- Naming and installed location of libraries, headers and executables (see discussion on kde-pim ML)
- Payload part labels are QStrings, attribute types are QByteArray
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.
- InnoDB tables should not be used on NFS.
- NFS speed: MySQL documentation recommends against locating its data files on network shares.
- 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.
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.
| 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: <>] |