Jump to content

KDE PIM/Akonadi Next/Legacy Akonadi Compatibility Layer: Difference between revisions

From KDE Community Wiki
Cmollekopf (talk | contribs)
Created page with "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 ent..."
 
Cmollekopf (talk | contribs)
No edit summary
 
(One intermediate revision by the same user not shown)
Line 8: Line 8:
Example usecase:  
Example usecase:  
* Mark as read + filter => Inter-resource move to local folder. The editor still holds the id while viewing.
* Mark as read + filter => Inter-resource move to local folder. The editor still holds the id while viewing.
* Collection-Id's in folders
* 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).

Latest revision as of 19:00, 9 December 2014

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).