| This file defines the "sync API", an interface to the syncer |
| backend that exposes (1) the core functionality of maintaining a consistent |
| local snapshot of a hierarchical object set; (2) a means to transactionally |
| access and modify those objects; (3) a means to control client/server |
| synchronization tasks, namely: pushing local object modifications to a |
| server, pulling nonlocal object modifications from a server to this client, |
| and resolving conflicts that may arise between the two; and (4) an |
| abstraction of some external functionality that is to be provided by the |
| host environment. |
| |
| This interface is used as the entry point into the syncer backend |
| when the backend is compiled as a library and embedded in another |
| application. A goal for this interface layer is to depend on very few |
| external types, so that an application can use the sync backend |
| without introducing a dependency on specific types. A non-goal is to |
| have binary compatibility across versions or compilers; this allows the |
| interface to use C++ classes. An application wishing to use the sync API |
| should ideally compile the syncer backend and this API as part of the |
| application's own build, to avoid e.g. mismatches in calling convention, |
| structure padding, or name mangling that could arise if there were a |
| compiler mismatch. |
| |
| The schema of the objects in the sync domain is based on the model, which |
| is essentially a hierarchy of items and folders similar to a filesystem, |
| but with a few important differences. The sync API contains fields |
| such as URL to easily allow the embedding application to store web |
| browser bookmarks. Also, the sync API allows duplicate titles in a parent. |
| Consequently, it does not support looking up an object by title |
| and parent, since such a lookup is not uniquely determined. Lastly, |
| unlike a filesystem model, objects in the Sync API model have a strict |
| ordering within a parent; the position is manipulable by callers, and |
| children of a node can be enumerated in the order of their position. |