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