Difference between revisions of "KDE PIM/Akonadi Next/Terminology"

(Created page with "== Glossary of Akonadi-Next Terms == ; akonadi1 : The current akonadi implementation that uses a central server and an SQL database ; akonadi-next: This is the codename for th...")
 
Line 3: Line 3:
 
; akonadi-next: 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.
 
; akonadi-next: 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.
 
; client: any application which accesses data using akonadi
 
; client: any application which accesses data using akonadi
; entity: 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.
+
; entity: 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.
; revision: 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.
+
; revision: 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.
; source: the canonical data set, which may be a remote IMAP server, a local iCal file, a local maildir, etc.
+
; source: The canonical data set, which may be a remote IMAP server, a local iCal file, a local maildir, etc.
; store: 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.
+
; store: 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.
; resource: 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.
+
; resource: 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.
; synchronizer: 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.
+
; synchronizer: 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.
; filter: 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)
+
; filter: 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)
; pipeline: 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)
+
; pipeline: 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)
; query: a declarative method for requesting entities from one or more sources that match a given set of constraints
+
; query: A declarative method for requesting entities from one or more sources that match a given set of constraints
; command: clients request modifications, additions and deletions to the store by sending commands to a synchronizer for processing
+
; command: 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
 
; command queue: a queue of commands kept by the synchronizer to ensure durability and, when necessary, replayability
 
; notification: a message sent from a synchronizer to inform the client of a change in the store
 
; notification: a message sent from a synchronizer to inform the client of a change in the store

Revision as of 17:35, 15 December 2014

Glossary of Akonadi-Next Terms

akonadi1 
The current akonadi implementation that uses a central server and an SQL database
akonadi-next
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.
client
any application which accesses data using akonadi
entity
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.
revision
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.
source
The canonical data set, which may be a remote IMAP server, a local iCal file, a local maildir, etc.
store
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.
resource
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.
synchronizer
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.
filter
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)
pipeline
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)
query
A declarative method for requesting entities from one or more sources that match a given set of constraints
command
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
notification
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.