diff options
author | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-12-28 13:52:46 +0100 |
---|---|---|
committer | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-12-28 13:52:46 +0100 |
commit | 296a5ac347dbccfff44d2b2a0a378e98b0480cac (patch) | |
tree | 2b27aa44b37752dd568a17ce43389ef10845d42b /docs/design.md | |
parent | d2654f78a4f7e87b44e296477e4d90646c967670 (diff) | |
download | sink-296a5ac347dbccfff44d2b2a0a378e98b0480cac.tar.gz sink-296a5ac347dbccfff44d2b2a0a378e98b0480cac.zip |
Docs
Diffstat (limited to 'docs/design.md')
-rw-r--r-- | docs/design.md | 16 |
1 files changed, 14 insertions, 2 deletions
diff --git a/docs/design.md b/docs/design.md index fe0d214..772bd65 100644 --- a/docs/design.md +++ b/docs/design.md | |||
@@ -39,6 +39,16 @@ Implications of the above: | |||
39 | 39 | ||
40 | # Overview | 40 | # Overview |
41 | 41 | ||
42 | ## Client API | ||
43 | The client facing API hides all akonadi internals from the applications and emulates a unified store that provides data through a standardized interface. | ||
44 | This allows applications to transparently use various data sources with various data source formats. | ||
45 | |||
46 | ## Resource | ||
47 | A resource is a plugin that provides access to an additional source. It consists of a store, a synchronizer process that executes synchronization & change replay to the source and maintains the store, as well as a facade plugin for the client api. | ||
48 | |||
49 | ## Store | ||
50 | Each resource maintains a store that can either store the full dataset for offline access or only metadata for quick lookups. Resources can define how data is stored. | ||
51 | |||
42 | ## Types | 52 | ## Types |
43 | ### Domain Type | 53 | ### Domain Type |
44 | The domain types exposed in the public interface. | 54 | The domain types exposed in the public interface. |
@@ -46,10 +56,12 @@ The domain types exposed in the public interface. | |||
46 | ### Buffer Type | 56 | ### Buffer Type |
47 | The individual buffer types as specified by the resource. The are internal types that don't necessarily have a 1:1 mapping to the domain types, although that is the default case that the default implementations expect. | 57 | The individual buffer types as specified by the resource. The are internal types that don't necessarily have a 1:1 mapping to the domain types, although that is the default case that the default implementations expect. |
48 | 58 | ||
59 | ## Mechanisms | ||
49 | ### Change Replay | 60 | ### Change Replay |
50 | The change replay is based on the revisions in the store. Clients (and also the write-back mechanism), are informed that a new revision is available. Each client can then go through all new revisions (starting from the last seen revision), and thus update it's state to the latest revision. | 61 | The change replay is based on the revisions in the store. Clients (as well as also the write-back mechanism that replays changes to the source), are informed that a new revision is available. Each client can then go through all new revisions (starting from the last seen revision), and thus update its state to the latest revision. |
51 | 62 | ||
52 | # Client API | 63 | ### Preprocessor pipeline |
64 | Each resource has an internal pipeline of preprocessors that can be used for tasks such as indexing or filtering. The pipeline guarantees that the preprocessor steps are executed before the entity is persisted. | ||
53 | 65 | ||
54 | # Tradeoffs/Design Decisions | 66 | # Tradeoffs/Design Decisions |
55 | * Key-Value store instead of relational | 67 | * Key-Value store instead of relational |