1Overview of chrome://sync-internals
2-----------------------------------
3
4This note explains how chrome://sync-internals (also known as
5about:sync) interacts with the sync service/backend.
6
7Basically, chrome://sync-internals sends asynchronous messages to the
8sync backend and the sync backend asynchronously raises events to
9chrome://sync-internals, either when replying to messages or when
10something interesting happens.
11
12Both messages and events have a name and a list of arguments, the
13latter of which is represented by a JsArgList (js_arg_list.h) object,
14which is basically a wrapper around an immutable ListValue.
15
16TODO(akalin): Move all the js_* files into a js/ subdirectory.
17
18Message/event flow
19------------------
20
21chrome://sync-internals is represented by SyncInternalsUI
22(chrome/browser/web_ui/sync_internals_ui.h).  SyncInternalsUI
23interacts with the sync service via a JsFrontend (js_frontend.h)
24object, which has a ProcessMessage() method.  The JsFrontend can
25handle some messages itself, but it can also delegate the rest to a
26JsBackend instance (js_backend.h), which also has a ProcessMessage()
27method.  A JsBackend can in turn handle some messages itself and
28delegate to other JsBackend instances.
29
30Essentially, there is a tree with a JsFrontend as the root and
31JsBackend as non-root internal nodes and leaf nodes (although
32currently, the tree is more like a simple list).  The sets of messages
33handled by the JsBackends and the JsFrontend are disjoint, which means
34that at most one node handles a given message type.  Also, the
35JsBackends may live on different threads, but JsArgList is thread-safe
36so that's okay.
37
38SyncInternalsUI is a JsEventHandler (js_event_handler.h), which means
39that it has a HandleJsEvent() method, but JsBackends cannot easily
40access those objects.  Instead, each JsBackend keeps track of its
41parent router, which is a JsEventRouter object (js_event_router.h).
42Basically, a JsEventRouter is another JsBackend object or a JsFrontend
43object.  So an event travels up through the JsEventRouter until it
44reaches the JsFrontend, which knows about the existing JsEventHandlers
45(via AddHandler()/RemoveHandler()) and so can delegate to the right
46one.
47
48A diagram of the flow of a message and its reply:
49
50msg(args) -> F -> B -> B -> B
51             |    |    |
52        H <- R <- R <- R <- reply-event(args)
53
54F = JsFrontend, B = JsBackend, R = JsEventRouter, H = JsEventHandler
55
56Non-reply events are percolated up similarly.
57