Home | History | Annotate | only in /external/chromium_org/sync/internal_api
Up to higher level directory
NameDateSize
base_node.cc06-Dec-201312.4K
base_transaction.cc06-Dec-2013951
change_record.cc06-Dec-20131.8K
change_reorder_buffer.cc06-Dec-20137.3K
change_reorder_buffer.h06-Dec-20133.2K
debug_info_event_listener.cc06-Dec-20139.9K
debug_info_event_listener.h06-Dec-20134.3K
debug_info_event_listener_unittest.cc06-Dec-20132K
delete_journal.cc06-Dec-20132.2K
DEPS06-Dec-2013247
http_bridge.cc06-Dec-201312.7K
http_bridge_unittest.cc06-Dec-201315K
internal_components_factory_impl.cc06-Dec-20132.5K
js_mutation_event_observer.cc06-Dec-20133.4K
js_mutation_event_observer.h06-Dec-20132.1K
js_mutation_event_observer_unittest.cc06-Dec-20133.7K
js_sync_encryption_handler_observer.cc06-Dec-20134.1K
js_sync_encryption_handler_observer.h06-Dec-20132.1K
js_sync_encryption_handler_observer_unittest.cc06-Dec-20136.1K
js_sync_manager_observer.cc06-Dec-20133.3K
js_sync_manager_observer.h06-Dec-20131.9K
js_sync_manager_observer_unittest.cc06-Dec-20134.6K
public/06-Dec-2013
read_node.cc06-Dec-20133.3K
read_transaction.cc06-Dec-20131.3K
README06-Dec-20132K
sync_encryption_handler_impl.cc06-Dec-201368.1K
sync_encryption_handler_impl.h06-Dec-201314K
sync_encryption_handler_impl_unittest.cc06-Dec-201396.3K
sync_manager_factory.cc06-Dec-2013575
sync_manager_impl.cc06-Dec-201346.1K
sync_manager_impl.h06-Dec-201315.2K
sync_manager_impl_unittest.cc06-Dec-2013133.8K
syncapi_internal.cc06-Dec-20133.1K
syncapi_internal.h06-Dec-20131.2K
syncapi_server_connection_manager.cc06-Dec-20133.7K
syncapi_server_connection_manager.h06-Dec-20132.6K
syncapi_server_connection_manager_unittest.cc06-Dec-20133.4K
test/06-Dec-2013
user_share.cc06-Dec-2013356
write_node.cc06-Dec-201319K
write_transaction.cc06-Dec-20131.4K

README

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