KDE PIM/Meetings/Akonadi Spring Sprint 2007
A group of KDE PIM developers met in Berlin from April 21st to April 22nd, 2007. The goal of the meeting was making progress on Akonadi, the PIM storage service planned to be the backend of the KDE 4 PIM application.
The meeting was hosted by KDAB in their shiny new Berlin offices.
Status of Akonadi Before the Meeting
To get everyone up to speed again, Volker has created a list with Akonadi changes since the meeting in Osnabrück. He also added a list of issues he would like to discuss. With those solved we should have all the functionality in Akonadi that was provided by the old KResources framework (and a lot more of course, but it would be the point were we could start using Akonadi in KDE PIM).
Changes since Osnabrück
Server
- basic cache management
- config file for database settings, additional support for MySQL (non-embedded)
- support arbitrary collection attributes
- no more DBus multithreading hacks :)
Resources
- change recording and replay
- generic collection synchronizer
- vCard and NNTP resources
libakonadi
- value-based collection API, collection are identified by id instead of by path now
- value-based item API (see below)
- Monitor now also fetches the changed object, simplifying application code
GSoC - Bruno Virlet is working on libakonadi model/view stuff:
- various model fixes, passing TT's modeltest
- proxy model to filter collections of a specific type
Open issues
Type-specific client API
How do we connect type-specifc libraries (libkabc, libkcal, etc) with Akonadi? The obvious choice would be inheriting from Akonadi::Item, but this would also require to re-implement every class returning an Item pointer. Also, there are ownership issues with a pointer-based API and Akonadi::Monitor. While a value-based API would be nice, it's still unknown how this could be done (templates?, Tobias had a design pattern in mind, I don't remember which one though).
Item data format
Related to above: how do we store PIM items, what format do we use to communicate with the backend?
Resource API
The current resource API is getting quite complex, mainly due to asynchronous operations. We need to review the current API and look for simplifications.
Another issue is the the amount of "magic" going on in Akonadi::ResourceBase (change compression, collection syncing), which is not accessible for unit tests.