KDE PIM/Akonadi Next/Legacy Akonadi Compatibility Layer

From KDE Community Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Example usecase:

  • Mark as read + filter => Inter-resource move to local folder. The editor still holds the id while viewing.
  • Collection-Id's in configurations

Compatibility notes:

  • 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).
Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/Akonadi_Next/Legacy_Akonadi_Compatibility_Layer&oldid=40751"