KDE PIM BoF at Akademy 2008

Summary

A group of KDE PIM developers met at Akademy 2008 to discuss plans for KDE 4.2.

The most important decision is probably that we want to deploy Akonadi for 4.2 for calendar and contact data. This is primarily done using Kevin's Akonadi <-> KResource bridges, which avoids the need to change anything in the applications and the backends. It will introduce overhead and likely new bugs, but it allows us to port applications and resources in small pieces instead of breaking everything for an extended period of time.

Meeting Minutes

KDE PIM/Akonadi BoF

Agenda
1 Akonadi feedback
2 KDE PIM planning for KDE 4.2
3 Akonadi planning for KDE 4.2

1 Feedback

Tom (Mailody)
- problem that nobody is using it
  -> bugs are not found/fixed
- small features missing: item size, ...

Bertjan (KPilot)
- ical/vcards backends are not working reliably

Dmitry's wish list (RSS GSoC)
- redo item sync and probably also collection sync
- fetching items filtered by important properties (e.g. all contacts)
  -> correct solution: virtual collection
  -> fetching by mime type is needed eg. for stuff like KABC::StandardAddressbook
  -> fetching by remote id
- intermediate solution for searching:
  -> fix Nepomuk agent
  -> directly use SPARQL queries
- add collection id to itemChanged() signal
  -> can be added, but will require lots of changes in observer API and other APIs
  -> no high priority, collection can be encoded in item remote id
- possibility to add items to virtual collections (similar to hard links)
  -> will be needed for "search in resource" functionality


2 KDE PIM 4.2

Do we want to port KAddressBook and KOrganizer to Akonadi for KDE 4.2?

Problem: KAddressBook/KOrganizer assume all data is in memory and all access is synchronous.
-> Porting is a huge effort (make all data access asynchronous, use monitoring)
-> KOrganizer (in the UI code) explicitly assumes calendar resource.
-> Initially (for KDE 4.2) use the resource bridges.
   -> still some work needed in the bridges to support sub-resources
   -> existing native backends (ical/vcard) need some work: robustness, support remote files, support legacy formats, etc.

Conclusion:
We will go for the bridge based migration. This causes no actual change to existing user data and settings unless the migration tool run, giving us an "emergency stop" option to be used in case the bridges and/or the migration tool are not ready for 4.2.

- Error handling in apps if Akonadi server is not present needs to be added.

People who want to help should
- Focus on making the current Akonadi resources and the bridges work.
- Focus on converting the old KResouces to proper Akonadi resources.

The applications (KAddressBook/KOrganizer) should not be ported before Akonadi is really stable, to preserve the emergency abort option mentioned above.

An Akonadi meeting is planned for early November, before the hard feature freeze for 4.2, likely the point where we will decide if we want to commit to the migration for 4.2.

For KMail:
- Split/refactor into components.
- Port components one at a time.
- For 4.2: Use header view (from SoC project).
- Not much else happening there for 4.2.


3 Akonadi 4.2 planning

-> see wiki page with tasks, main focus are resource bridges, migration tools and solving the current deployment issues

[ Edit ]