KDE PIM/Akonadi Next/Terminology

Glossary of Akonadi-Next Terms

The current akonadi implementation that uses a central server and an SQL database
This is the codename for the project. In the long run this is supposed to be folded into regular akonadi, so we will never release a product called akonadi-next.
any application which accesses data using akonadi
The atomic unit for a given type of data. An email is an entity; an email folder is an entity; a calendar event is an entity; a contact is an entity; etc. Different kinds of entities may have their own data structure, but conceptually they are equivalent in most other ways.
A version of an entity. One entity may have multiple revisions in a store, representing (for instance) the local state and the synchronized state of the entity.
The canonical data set, which may be a remote IMAP server, a local iCal file, a local maildir, etc.
The local, persistent (e.g. on disk) record of entities belonging to a source. This may be a full mirror of the data or simply metadata, a detail left up to the resource. The format of the data in the store is defined by the resource that owns it.
A plugin which provides a client command processor, data facade and synchronization service for a given type of store. The resource also manages the configuration for a given source including server settings, local paths, etc.
The operating system process responsible for overseeing the process of modifying and synchronizing a store. To accomplish this, a synchronizer loads the correct resource plugin, manages pipelines and handles client communication. One synchronizer is created for each source that is accessed by clients; these processes are shared by all clients.
A component that takes an entity and performs some modification of it (e.g. changes the folder an email is in) or processes it in some way (e.g. indexes it)
A run-time definable set of filters which are applied to an entity after a resource has performed a specific kind of function on it (add, update, remove)
A declarative method for requesting entities from one or more sources that match a given set of constraints
Clients request modifications, additions and deletions to the store by sending commands to a synchronizer for processing
command queue
A queue of commands kept by the synchronizer to ensure durability and, when necessary, replayability
A message sent from a synchronizer to inform the client of a change in the store

Content is available under Creative Commons License SA 4.0 unless otherwise noted.