diff options
Diffstat (limited to 'docs/resource.md')
-rw-r--r-- | docs/resource.md | 42 |
1 files changed, 42 insertions, 0 deletions
diff --git a/docs/resource.md b/docs/resource.md new file mode 100644 index 0000000..847831d --- /dev/null +++ b/docs/resource.md | |||
@@ -0,0 +1,42 @@ | |||
1 | The resource consists of: | ||
2 | |||
3 | * the syncronizer process | ||
4 | * a plugin providing the client-api facade | ||
5 | * a configuration setting up the filters | ||
6 | |||
7 | # Syncronizer | ||
8 | * The synchronization can either: | ||
9 | * 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. | ||
10 | * If the source supports incremental changes the changeset can directly be generated from that information. | ||
11 | |||
12 | The changeset is then simply inserted in the regular modification queue and processed like all other modifications. | ||
13 | The synchronizer already knows that it doesn't have to replay this changeset to the source, since replay no longer goes via the store. | ||
14 | |||
15 | # Preprocessors | ||
16 | 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. | ||
17 | |||
18 | Usecases: | ||
19 | |||
20 | * Updating various indexes | ||
21 | * detecting spam/scam mail and setting appropriate flags | ||
22 | * email filtering | ||
23 | |||
24 | Preprocessors need to be fast, since they directly affect how fast a message is processed by the system. | ||
25 | |||
26 | The following kinds of preprocessors exist: | ||
27 | |||
28 | * filtering preprocessors that can potentially move an entity to another resource | ||
29 | * passive filter, that extract data that is stored externally (i.e. indexers) | ||
30 | * flag extractors, that produce data stored with the entity (spam detection) | ||
31 | |||
32 | Filter typically be read-only, to i.e. not break signatures of emails. Extra flags that are accessible through the akonadi domain model, can therefore be stored in the local buffer of each resource. | ||
33 | |||
34 | # Generic Preprocessors | ||
35 | Most preprocessors will likely be used by several resources, and are either completely generic, or domain specific (such as only for mail). | ||
36 | It is therefore desirable to have default implementations for common preprocessors that are ready to be plugged in. | ||
37 | |||
38 | The domain types provide a generic interface to access most properties of the entities, on top of which generic preprocessors can be implemented. | ||
39 | It is that way trivial to i.e. implement a preprocessor that populates a hierarchy index of collections. | ||
40 | |||
41 | # Pipeline | ||
42 | 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. | ||