Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(2751)

Unified Diff: chrome/browser/sync/internal_api/README

Issue 7624009: Original patch by rlarocque@chromium.org at http://codereview.chromium.org/7633077/ (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: Fix windows build pt5 Created 9 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « chrome/browser/sync/internal_api/DEPS ('k') | chrome/browser/sync/internal_api/base_node.h » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: chrome/browser/sync/internal_api/README
diff --git a/chrome/browser/sync/internal_api/README b/chrome/browser/sync/internal_api/README
new file mode 100644
index 0000000000000000000000000000000000000000..32987bbab9d03ec4dfaf5818fd577427c4132d67
--- /dev/null
+++ b/chrome/browser/sync/internal_api/README
@@ -0,0 +1,32 @@
+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.
« no previous file with comments | « chrome/browser/sync/internal_api/DEPS ('k') | chrome/browser/sync/internal_api/base_node.h » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698