KDE PIM/Meetings/Akonadi Spring Sprint 2007: Difference between revisions
Mahoutsukai (talk | contribs) (add info about Akonadi Sprint Sprint 2007 in Berlin) |
Mahoutsukai (talk | contribs) mNo edit summary |
||
| Line 7: | Line 7: | ||
[http://www.klaralvdalens-datakonsult.se/ KDAB] in their shiny new | [http://www.klaralvdalens-datakonsult.se/ KDAB] in their shiny new | ||
Berlin offices. | Berlin offices. | ||
== Status of Akonadi Before the Meeting == | == Status of Akonadi Before the Meeting == | ||
| Line 16: | Line 15: | ||
that was provided by the old KResources framework (and a lot more of course, | 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). | but it would be the point were we could start using Akonadi in KDE PIM). | ||
=== Changes since Osnabrück === | === Changes since Osnabrück === | ||
| Line 42: | Line 40: | ||
* various model fixes, passing TT's modeltest | * various model fixes, passing TT's modeltest | ||
* proxy model to filter collections of a specific type | * proxy model to filter collections of a specific type | ||
=== Open issues === | === Open issues === | ||
| Line 55: | Line 52: | ||
done (templates?, Tobias had a design pattern in mind, I don't remember which | done (templates?, Tobias had a design pattern in mind, I don't remember which | ||
one though). | one though). | ||
==== Item data format ==== | ==== Item data format ==== | ||
| Line 61: | Line 57: | ||
Related to above: how do we store PIM items, what format do we use to | Related to above: how do we store PIM items, what format do we use to | ||
communicate with the backend? | communicate with the backend? | ||
==== Resource API ==== | ==== Resource API ==== | ||
Latest revision as of 15:06, 27 February 2011
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.