KDE PIM/Akonadi Next/Legacy Akonadi Compatibility Layer: Difference between revisions
< KDE PIM | Akonadi Next
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 |
||
| 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 | * Collection-Id's in configurations | ||
Revision as of 11:21, 2 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