KDE PIM/Akonadi Next/Resource: Difference between revisions
Cmollekopf (talk | contribs) Created page with "The resource consists of: * the syncronizer process * a plugin providing the client-api facade * a configuration setting up the filters === Syncronizer === * The synchronizat..." |
Cmollekopf (talk | contribs) No edit summary |
||
| Line 11: | Line 11: | ||
The changeset is then simply inserted in the regular modification queue and processed like all other modifications. | The changeset is then simply inserted in the regular modification queue and processed like all other modifications. | ||
The synchronizer already knows that it doesn't have to replay this changeset to the source, since replay no longer goes via the store. | The synchronizer already knows that it doesn't have to replay this changeset to the source, since replay no longer goes via the store. | ||
=== Preprocessors === | |||
Preprocessors are small processors that are guaranteed to be processed before an new/modified/deleted entity reaches storage. The can therefore be used for various tasks that need to be executed on every entity. | |||
Usecases: | |||
* Updating various indexes | |||
* detecting spam/scam mail and setting appropriate flags | |||
* email filtering | |||
Preprocessors need to be fast, since they directly affect how fast a message is processed by the system. | |||
==== Generic Preprocessors ==== | |||
Most preprocessors will likely be used by several resources, and are either completely generic, or domain specific (such as only for mail). | |||
It is therefore desirable to have default implementations for common preprocessors that are ready to be plugged in. | |||
The domain types provide a generic interface to access most properties of the entities, on top of which generic preprocessors can be implemented. | |||
It is that way trivial to i.e. implement a preprocessor that populates a hierarchy index of collections. | |||
=== Pipeline === | |||
A pipeline is an assembly of a set of preprocessors with a defined order. A modification is always persisted at the end of the pipeline once all preprocessors have been processed. | |||
Revision as of 00:29, 23 December 2014
The resource consists of:
- the syncronizer process
- a plugin providing the client-api facade
- a configuration setting up the filters
Syncronizer
- The synchronization can either:
- Generate a full diff directly on top of the db. The diffing process can work against a single revision, and could even stop writing other changes to disk while the process is ongoing (but doesn't have to due to the revision). It then generates a necessary changeset for the store.
- If the source supports incremental changes the changeset can directly be generated from that information.
The changeset is then simply inserted in the regular modification queue and processed like all other modifications. The synchronizer already knows that it doesn't have to replay this changeset to the source, since replay no longer goes via the store.
Preprocessors
Preprocessors are small processors that are guaranteed to be processed before an new/modified/deleted entity reaches storage. The can therefore be used for various tasks that need to be executed on every entity.
Usecases:
- Updating various indexes
- detecting spam/scam mail and setting appropriate flags
- email filtering
Preprocessors need to be fast, since they directly affect how fast a message is processed by the system.
Generic Preprocessors
Most preprocessors will likely be used by several resources, and are either completely generic, or domain specific (such as only for mail). It is therefore desirable to have default implementations for common preprocessors that are ready to be plugged in.
The domain types provide a generic interface to access most properties of the entities, on top of which generic preprocessors can be implemented. It is that way trivial to i.e. implement a preprocessor that populates a hierarchy index of collections.
Pipeline
A pipeline is an assembly of a set of preprocessors with a defined order. A modification is always persisted at the end of the pipeline once all preprocessors have been processed.