Remove Sync JS generic request/reply framework

With the conversion of GetAllNodes in r262193, there are no longer any
uses of the Sync JS framework's request + reply framework.

The generic framework was useful when we could guarantee that the
requests would be handled in order, in the SyncManager, and on the sync
thread, but new requirements have forced us to re-implement much of this
functionality in other ways.

Since no one uses this code, and no one plans to use this code, and it
depends on some semi-deprecated concepts (WeakHandle), the best course
of action seems to be to delete it.  We can always fetch it from SVN
history and clean it up if we find another use for it.

BUG=328606,357821

Review URL: https://codereview.chromium.org/231013003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@263105 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 16 insertions, 48 deletions

diff --git a/sync/js/README.js b/sync/js/README.js
index 0fbfa66..3a99d1e 100644
--- a/sync/js/README.js
+++ b/sync/js/README.js
@@ -1,48 +1,16 @@
-Overview of chrome://sync-internals
------------------------------------
-
-This note explains how chrome://sync-internals (also known as
-about:sync) interacts with the sync service/backend.
-
-Basically, chrome://sync-internals sends messages to the sync backend
-and the sync backend sends the reply asynchronously.  The sync backend
-also asynchronously raises events which chrome://sync-internals listen
-to.
-
-A message and its reply has a name and a list of arguments, which is
-basically a wrapper around an immutable ListValue.
-
-An event has a name and a details object, which is represented by a
-JsEventDetails (js_event_details.h) object, which is basically a
-wrapper around an immutable DictionaryValue.
-
-Message/event flow
-------------------
-
-chrome://sync-internals is represented by SyncInternalsUI
-(chrome/browser/ui/webui/sync_internals_ui.h).  SyncInternalsUI
-interacts with the sync service via a JsController (js_controller.h)
-object, which has a ProcessJsMessage() method that just delegates to
-an underlying JsBackend instance (js_backend.h).  The SyncInternalsUI
-object also registers itself (as a JsEventHandler
-[js_event_handler.h]) to the JsController object, and any events
-raised by the JsBackend are propagated to the JsController and then to
-the registered JsEventHandlers.
-
-The ProcessJsMessage() takes a WeakHandle (weak_handle.h) to a
-JsReplyHandler (js_reply_handler.h), which the backend uses to send
-replies safely across threads.  SyncInternalsUI implements
-JsReplyHandler, so it simply passes itself as the reply handler when
-it calls ProcessJsMessage() on the JsController.
-
-The following objects live on the UI thread:
-
-- SyncInternalsUI (implements JsEventHandler, JsReplyHandler)
-- SyncJsController (implements JsController, JsEventHandler)
-
-The following objects live on the sync thread:
-
-- SyncManager::SyncInternal (implements JsBackend)
-
-Of course, none of these objects need to know where the other objects
-live, since they interact via WeakHandles.
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+This framework was once used to implement an asynchronous request/reply
+protocol between the chrome://sync-internals page and the sync backend thread.
+Much of it has been removed in favor of an ad-hoc system that allows us to
+offer better safety guarantees, and to dispatch requests to different threads.
+
+All that remains are some WeakHandles that allow us to send JsEvents from the
+sync backend to about:sync.  The SyncInternalsUI implements JsEventHandler in
+order to receive these events.  The SyncManager implements JsBackend in order
+to send them.  The SyncJsController acts as an intermediary between them.
+
+The old framework may still be useful to someone.  Feel free to retrieve it
+from SVN history if you feel you can make use of it.