diff options
| author | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-10-30 19:41:01 +0100 |
|---|---|---|
| committer | Christian Mollekopf <chrigi_1@fastmail.fm> | 2015-10-30 19:41:01 +0100 |
| commit | 8d59bbdebcca2293d5b3b1da903c39845f7ba1a9 (patch) | |
| tree | a128226b311edf18ccd509fd8a8d6cb90abc3d1a /docs/clientapi.md | |
| parent | 0a2d20c474206553d5c981fd2a772188083101e9 (diff) | |
| download | sink-8d59bbdebcca2293d5b3b1da903c39845f7ba1a9.tar.gz sink-8d59bbdebcca2293d5b3b1da903c39845f7ba1a9.zip | |
docs
Diffstat (limited to 'docs/clientapi.md')
| -rw-r--r-- | docs/clientapi.md | 30 |
1 files changed, 3 insertions, 27 deletions
diff --git a/docs/clientapi.md b/docs/clientapi.md index 59998ca..58fbb13 100644 --- a/docs/clientapi.md +++ b/docs/clientapi.md | |||
| @@ -17,35 +17,11 @@ The client API consists of: | |||
| 17 | A set of standardized domain types is defined. This is necessary to decouple applications from resources (so a calendar can access events from all resources), and to have a "language" for queries. | 17 | A set of standardized domain types is defined. This is necessary to decouple applications from resources (so a calendar can access events from all resources), and to have a "language" for queries. |
| 18 | 18 | ||
| 19 | The definition of the domain model directly affects: | 19 | The definition of the domain model directly affects: |
| 20 | * granularity for data retrievel (email property, or individual subject, date, ...) | 20 | * granularity for data retrieval (email property, or individual subject, date, ...) |
| 21 | * queriable properties (sender, id, ...) | 21 | * queriable properties for filtering and sorting (sender, id, ...) |
| 22 | * properties used for sorting (10 latest email) | ||
| 23 | 22 | ||
| 24 | The purpose of these domain types is strictly to be the interface and the types are not meant to be used by applications directly, or to be restricted by any other specifications (such as ical). By nature these types will be part of the evolving interface, and will need to be adjusted for every new property that an application must understand. | 23 | The purpose of these domain types is strictly to be the interface and the types are not meant to be used by applications directly, or to be restricted by any other specifications (such as ical). By nature these types will be part of the evolving interface, and will need to be adjusted for every new property that an application must understand. |
| 25 | 24 | ||
| 26 | ### Application Domain Types | ||
| 27 | This is a proposed set of types that we will need to evolve into what we actually require. Hierarchical types are required to be able to query for a result set of mixed types. | ||
| 28 | |||
| 29 | * Entity | ||
| 30 | * Item | ||
| 31 | * Incidence | ||
| 32 | * Event | ||
| 33 | * Todo | ||
| 34 | * Journal | ||
| 35 | * Freebusy | ||
| 36 | * Note | ||
| 37 | |||
| 38 | * Contact | ||
| 39 | * Collection | ||
| 40 | * Mail Folder | ||
| 41 | * Calendar | ||
| 42 | * Tasklist | ||
| 43 | * Journal | ||
| 44 | * Contact Group | ||
| 45 | * Address Book | ||
| 46 | * Relation | ||
| 47 | * Tag | ||
| 48 | |||
| 49 | ## Store Facade | 25 | ## Store Facade |
| 50 | The store is always accessed through a store specific facade, which hides: | 26 | The store is always accessed through a store specific facade, which hides: |
| 51 | * store access (one store could use a database, and another one plain files) | 27 | * store access (one store could use a database, and another one plain files) |
| @@ -72,7 +48,7 @@ The changeset can be recorded by the domain object adapter while the properties | |||
| 72 | Each modification is associated with a specific revision, which allows the synchronizer to do automatic conflict resolution. | 48 | Each modification is associated with a specific revision, which allows the synchronizer to do automatic conflict resolution. |
| 73 | 49 | ||
| 74 | ### Conflict Resolution | 50 | ### Conflict Resolution |
| 75 | Conflicts can occur at two points in the client: | 51 | Conflicts can occur at two points: |
| 76 | 52 | ||
| 77 | * While i.e. an editor is open and we receive an update for the same entity | 53 | * While i.e. an editor is open and we receive an update for the same entity |
| 78 | * After a modification is sent to the synchronizer but before it's processed | 54 | * After a modification is sent to the synchronizer but before it's processed |