KDE PIM/Akonadi: Difference between revisions

From KDE TechBase
(Various updates.)
Line 19: Line 19:
{{FeatureTodo|Undo framework||}}
{{FeatureTodo|Undo framework||}}
{{FeatureInProgress|Action framework|see below|Volker|[email protected]}}
{{FeatureInProgress|Action framework|see below|Volker|[email protected]}}
{{FeatureTodo|Server-side copy|for items and collections|}}
{{FeatureDone|Server-side copy|for items and collections|Volker|[email protected]}}
{{FeatureTodo|Finish collection model/view|see below|}}
{{FeatureTodo|Finish collection model/view|see below|}}
{{FeatureTodo|Solid integration|Switch online/offline state in ResourceBase automatically|}}
{{FeatureTodo|Solid integration|Switch online/offline state in ResourceBase automatically|}}
{{FeatureTodo|Hierarchical dptrs|Use for all job classes, check where else this makes sense|}}
{{FeatureTodo|Hierarchical dptrs|Use for all job classes, check where else this makes sense|}}
{{FeatureTodo|Make unittests work without destroying the production database||}}
{{FeatureTodo|Make unittests work without destroying the production database||}}
{{FeatureTodo|Backup support|Dump & Restore database contents, also useful when upgrading to a newer database version|}}
{{FeatureTodo|Error reporting|Akonadi::Job basically has only one error code: Unknown|}}
|}
|}


Line 34: Line 36:
! Type !! Serializer !! Multipart Support !! Models !! Views !! Resources !! Notes
! Type !! Serializer !! Multipart Support !! Models !! Views !! Resources !! Notes
|-
|-
|Email||yes||partial||MessageModel, MessageCollectionModel, threading proxy model||?||maildir||threading agent
|Email||yes||partial||MessageModel, MessageCollectionModel, threading proxy model||?||maildir, IMAP||threading agent
|-
|-
|News||yes (1)||partial (1)||(1)||(1)||NNTP||
|News||yes (1)||partial (1)||(1)||(1)||NNTP||
Line 65: Line 67:
! Status !! Item !! Description !! Contact
! Status !! Item !! Description !! Contact
{{FeatureTodo|Todo proxy model|See KOrganizers To-Do view|Bruno?}}
{{FeatureTodo|Todo proxy model|See KOrganizers To-Do view|Bruno?}}
{{FeatureInProgress|Subtype identification|See discussion on kde-pim mailinglist|Kevin?}}
{{FeatureTodo|Agenda view|KOrganizer agenda view based on Akonadi|Bruno?}}
{{FeatureTodo|Month view|KOrganizer month view based on Akonadi|Bruno?}}
{{FeatureTodo|Timeline view|KOrganizer timeline view based on Akonadi|}}
|}
|}


Line 140: Line 146:
* copy collection [done]
* copy collection [done]
* cut collection
* cut collection
* paste collection
* paste collection [done]
* synchronize collection [done for single selection]
* synchronize collection [done for single selection]
* synchronize resource
* synchronize everything
* show collection properties dialog [done]
* show collection properties dialog [done]
* delete item(s)
* delete item(s)
* copy item(s)
* copy item(s) [done]
* cut item(s)
* cut item(s)
* paste item(s)
* paste item(s) [done]
* paste native data
* paste native data
* tag item(s)
* tag item(s)
Line 154: Line 162:
* add resource? (would need a type parameter, etc.)
* add resource? (would need a type parameter, etc.)
* delete resource
* delete resource
* manage local subscriptions [done]
* move to submenu
* copy to submenu


The list is definitely long enough to make this worthwhile.
The list is definitely long enough to make this worthwhile.
Line 178: Line 189:
* 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)
* 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?
* We currently use 32 bit ids, probably hard to change later on, is that enough?
=== API issues ===
Smaller stuff that should be fixed in the API before the 4.1 freeze and is not yet listed above:
* Hierarchical dptrs where useful
* /WId/QWidget*/ and call widget->window()->winId() internally (also helps with Qt4.4 Allien)
* CollectionView ctor prevent usage via Qt Designer
* Cleanup the D-Bus format used by NotificationMessage
* No mentioning of "IMAP" in the public API, we are not using IMAP
* Kill DataReference and fold it back in Item
* ItemStoreJob( _non const_ Item &item ) is extremely error prone
* Kill ResourceBase::settings()
* The built-in sorting issue in CollectionView (see kde-pim ML)


== KMail Breakdown Plan ==
== KMail Breakdown Plan ==

Revision as of 13:47, 8 March 2008

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: <>]
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: <>]
IN PROGRESS Action framework see below [email protected] <Volker>
DONE Server-side copy for items and collections [email protected] <Volker>
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 [mailto: <>]
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: <>]

Supported Types

Overview on the current state of support for various types:

Type Serializer Multipart Support Models Views Resources Notes
Email 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
Facebook ? ? ? ? ? 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)
  • 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)

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?

API issues

Smaller stuff that should be fixed in the API before the 4.1 freeze and is not yet listed above:

  • Hierarchical dptrs where useful
  • /WId/QWidget*/ and call widget->window()->winId() internally (also helps with Qt4.4 Allien)
  • CollectionView ctor prevent usage via Qt Designer
  • Cleanup the D-Bus format used by NotificationMessage
  • No mentioning of "IMAP" in the public API, we are not using IMAP
  • Kill DataReference and fold it back in Item
  • ItemStoreJob( _non const_ Item &item ) is extremely error prone
  • Kill ResourceBase::settings()
  • The built-in sorting issue in CollectionView (see kde-pim ML)

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: <>]
Retrieved from "https://techbase.kde.org/index.php?title=KDE_PIM/Akonadi&oldid=21749"