diff options
Diffstat (limited to 'docs/design.md')
| -rw-r--r-- | docs/design.md | 23 |
1 files changed, 7 insertions, 16 deletions
diff --git a/docs/design.md b/docs/design.md index 59cdf74..fe0d214 100644 --- a/docs/design.md +++ b/docs/design.md | |||
| @@ -1,4 +1,4 @@ | |||
| 1 | # Goals | 1 | # Design Goals |
| 2 | ## Axioms | 2 | ## Axioms |
| 3 | 1. Personal information is stored in multiple sources (address books, email stores, calendar files, ...) | 3 | 1. Personal information is stored in multiple sources (address books, email stores, calendar files, ...) |
| 4 | 2. These sources may local, remote or a mix of local and remote | 4 | 2. These sources may local, remote or a mix of local and remote |
| @@ -39,27 +39,18 @@ Implications of the above: | |||
| 39 | 39 | ||
| 40 | # Overview | 40 | # Overview |
| 41 | 41 | ||
| 42 | # Types | 42 | ## Types |
| 43 | ## Domain Type | 43 | ### Domain Type |
| 44 | The domain types exposed in the public interface. | 44 | The domain types exposed in the public interface. |
| 45 | 45 | ||
| 46 | ## Buffer Type | 46 | ### 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. | 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. |
| 48 | 48 | ||
| 49 | ## Steps to add support for new types | 49 | ### Change Replay |
| 50 | * Add new type to applicationdomaintypes.h and implement `getTypenName()` | ||
| 51 | * Implement `TypeImplementation<>` for updating indexes etc. | ||
| 52 | * Add a type.fbs default schema for the type | ||
| 53 | |||
| 54 | ## Steps for adding support for a type to a resource | ||
| 55 | * Add a TypeAdaptorFactory, which can either register resource specific mappers, or stick to what the default implementation in TypeImplementation provides | ||
| 56 | * Add a TypeFacade that injects the TypeAdaptorFactory in the GenericFacade | ||
| 57 | * Register the facade in the resource | ||
| 58 | * Add synchronization code that creates the relevant objects | ||
| 59 | |||
| 60 | # Change Replay | ||
| 61 | 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. | 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. |
| 62 | 51 | ||
| 52 | # Client API | ||
| 53 | |||
| 63 | # Tradeoffs/Design Decisions | 54 | # Tradeoffs/Design Decisions |
| 64 | * Key-Value store instead of relational | 55 | * Key-Value store instead of relational |
| 65 | * `+` Schemaless, easier to evolve | 56 | * `+` Schemaless, easier to evolve |