KDE PIM/Akonadi Next/Legacy Akonadi Compatibility Layer
A compatibility layer is required in order to keep the current API working. This includes the Akonadi:: jobs and Akonadi::Monitor.
- akonadi provided a stable id for each entity, that also didn't change over moves.
- since the new akonadi no longer provides this, especially not accross resources, a persistent mapping is required.
Akonadi::Entity::Id <=> Resource+Id
- Mark as read + filter => Inter-resource move to local folder. The editor still holds the id while viewing.
- Collection-Id's in configurations
- Tags/Relations now need a target resource on creation. This is a change from the current situation where you can just create a tag, and every resource can synchronize it. It requires a bit more work but results also in a more predictable system, which we'll also need if we want to support different tag storage locations (shared tag set in a shared folder).
This page was last edited on 9 December 2014, at 19:00. Content is available under Creative Commons License SA 4.0 unless otherwise noted.