KDE PIM/Akonadi

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]>
IN PROGRESS	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: <>]
TO DO	API for additional item parts	As discussed in Osnabruck	[mailto: <>]
TO DO	Infrastructure for showing additional dialogs from agents/resources	As discussed in Osnabrueck	[mailto: <>]
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: <>]
TO DO	Fix API for item/collection modifications	See Osnabrueck meeting notes for details	[mailto: <>]
TO DO	Remove DataReference	Fold back into Item	[mailto: <>]
TO DO	Undo framework		[mailto: <>]
TO DO	Action framework	see below	<Volker?>
TO DO	Server-side copy	for items and collections	[mailto: <>]

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?>

Resources, Agents and others

Status	Item	Description	Contact
IN PROGRESS	KResource Akonadi bridge	for KCal and KABC	<Kevin>
TO DO	Akonadi KResource bridge		<Kevin>
TO DO	Expire Agent		[mailto: <>]
TO DO	MBOX Resource		<Thomas>
TO DO	Extend IMAP Resource		[mailto: <>]
TO DO	POP3 Resource		<Thomas>
TO DO	Filter Agent		[mailto: <>]
TO DO	Search		[mailto: <>]
TO DO	Filter Rule GUI	Used by filters and searches	[mailto: <>]

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
• new virtual collection
• delete collection
• copy collection
• cut collection
• paste collection
• synchronize collection
• show collection
• delete item(s)
• copy item(s)
• cut item(s)
• paste item(s)
• paste native data
• tag item(s)
• comment item
• rate item(s)

The list is definitely long enough to make this worthwhile.

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: <>]