+monitor
+.......
+
+Request object members:
+
+ "method": "monitor" required
+ "params": [<db-name>, <json-value>, <monitor-requests>] required
+ "id": <nonnull-json-value> required
+
+<monitor-requests> is an object that maps from a table name to an
+array of <monitor-request> objects. For backward compatibility, a
+single <monitor-request> may be used instead of an array; it is
+treated as a single-element array.
+
+Each <monitor-request> is an object with the following members:
+
+ "columns": [<column>*] optional
+ "select": <monitor-select> optional
+
+<monitor-select> is an object with the following members:
+
+ "initial": <boolean> optional
+ "insert": <boolean> optional
+ "delete": <boolean> optional
+ "modify": <boolean> optional
+
+Response object members:
+
+ "result": <table-updates>
+ "error": null
+ "id": same "id" as request
+
+This JSON-RPC request enables a client to replicate tables or subsets
+of tables within database <db-name>. Each element of
+<monitor-requests> specifies a table to be replicated. The JSON-RPC
+response to the "monitor" includes the initial contents of each table,
+unless disabled (see below). Afterward, when changes to those tables
+are committed, the changes are automatically sent to the client using
+the "update" monitor notification. This monitoring persists until the
+JSON-RPC session terminates or until the client sends a
+"monitor_cancel" JSON-RPC request.
+
+Each <monitor-request> describes how to monitor columns in a table:
+
+ The circumstances in which an "update" notification is sent for a
+ row within the table are determined by <monitor-select>:
+
+ If "initial" is omitted or true, every row in the table is
+ sent as part of the reply to the "monitor" request.
+
+ If "insert" is omitted or true, "update" notifications are
+ sent for rows newly inserted into the table.
+
+ If "delete" is omitted or true, "update" notifications are
+ sent for rows deleted from the table.
+
+ If "modify" is omitted or true, "update" notifications are
+ sent whenever when a row in the table is modified.
+
+ The "columns" member specifies the columns whose values are
+ monitored. It must not contain duplicates. If "columns" is
+ omitted, all columns in the table, except for "_uuid", are
+ monitored.
+
+If there is more than one <monitor-request> in an array of them, then
+each <monitor-request> in the array should specify both "columns" and
+"select", and the "columns" must be non-overlapping sets.
+
+The "result" in the JSON-RPC response to the "monitor" request is a
+<table-updates> object (see below) that contains the contents of the
+tables for which "initial" rows are selected. If no tables' initial
+contents are requested, then "result" is an empty object.
+
+update
+......
+
+Notification object members:
+
+ "method": "update"
+ "params": [<json-value>, <table-updates>]
+ "id": null
+
+The <json-value> in "params" is the same as the value passed as the
+<json-value> in "params" for the "monitor" request.
+
+<table-updates> is an object that maps from a table name to a
+<table-update>.
+
+A <table-update> is an object that maps from the row's UUID (as a
+36-byte string) to a <row-update> object.
+
+A <row-update> is an object with the following members:
+
+ "old": <row> present for "delete" and "modify" updates
+ "new": <row> present for "initial", "insert", and "modify" updates
+
+This JSON-RPC notification is sent from the server to the client to
+tell it about changes to a monitored table (or the initial state of a
+modified table). Each table in which one or more rows has changed (or
+whose initial view is being presented) is represented in "updates".
+Each row that has changed (or whose initial view is being presented)
+is represented in its <table-update> as a member with its name taken
+from the row's _uuid member. The corresponding value is a
+<row-update>:
+
+ The "old" member is present for "delete" and "modify" updates.
+ For "delete" updates, each monitored column is included. For
+ "modify" updates, the prior value of each monitored column whose
+ value has changed is included (monitored columns that have not
+ changed are represented in "new").
+
+ The "new" member is present for "initial", "insert", and "modify"
+ updates. For "initial" and "insert" updates, each monitored
+ column is included. For "modify" updates, the new value of each
+ monitored column is included.
+
+monitor_cancel
+..............
+
+Request object members:
+
+ "method": "monitor_cancel" required
+ "params": [<json-value>] required
+ "id": <nonnull-json-value> required
+
+Response object members:
+
+ "result": {}
+ "error": null
+ "id": the request "id" member
+
+Cancels the ongoing table monitor request, identified by the
+<json-value> in "params" matching the <json-value> in "params" for an
+ongoing "monitor" request. No more "update" messages will be sent for
+this table monitor.
+
+lock operations
+...............
+
+Request object members:
+
+ "method": "lock", "steal", or "unlock" required
+ "params": [<id>] required
+ "id": <nonnull-json-value> required
+
+Response object members:
+
+ "result": {"locked": <boolean>} for "lock"
+ "result": {"locked": true} for "steal"
+ "result": {} for "unlock"
+ "error": null
+ "id": same "id" as request
+
+Performs an operation on a "lock" object. The database server
+supports an arbitrary number of locks, each of which is identified by
+a client-defined id (given in "params"). At any given time, each lock
+may have at most one owner.
+
+The locking operation depends on "method":
+
+ - "lock": The database will assign this client ownership of the
+ lock as soon as it becomes available. When multiple clients
+ request the same lock, they will receive it in first-come, first
+ served order.
+
+ - "steal": The database immediately assigns this client ownership
+ of the lock. If there is an existing owner, it loses ownership.
+
+ - "unlock": If the client owns the lock, releases it. If the
+ client is waiting to obtain the lock, cancels the request and
+ stops waiting.
+
+ (Closing or otherwise disconnecting a database client connection
+ unlocks all of its locks.)
+
+For any given lock, the client must alternate "lock" or "steal"
+operations with "unlock" operations. That is, if the previous
+operation on a lock was "lock" or "steal", it must be followed by an
+"unlock" operation, and vice versa.
+
+For a "lock" operation, the "locked" member in the response object is
+true if the lock has already been acquired, false if another client
+holds the lock and the client's request for it was queued. In the
+latter case, the client will be notified later with a "locked" message
+when acquisition succeeds.
+
+These requests complete and send a response quickly, without waiting.
+The "locked" and "stolen" notifications (see below) report
+asynchronous changes to ownership.
+
+The scope of a lock is a database server, not a database hosted by
+that server. A naming convention, such as "<db-name>__<lock-name>",
+can effectively limit the scope of a lock to a particular database.
+
+locked
+......
+
+Notification object members:
+
+ "method": "locked"
+ "params": [<id>]
+ "id": null
+
+Notifies the client that a "lock" operation that it previously
+requested has succeeded. The client now owns the lock named in
+"params".
+
+The database server sends this notification after the reply to the
+corresponding "lock" request (but only if the "locked" member of the
+response was false), and before the reply to the client's subsequent
+"unlock" request.
+
+stolen
+......
+
+Notification object members:
+
+ "method": "stolen"
+ "params": [<id>]
+ "id": null
+
+Notifies the client that owns a lock that another database client has
+stolen ownership of the lock. The client no longer owns the lock
+named in "params". The client must still issue an "unlock" request
+before performing any subsequent "lock" or "steal" operation on the
+lock.
+
+If the client originally obtained the lock through a "lock" request,
+then it will automatically regain the lock later after the client that
+stole it releases it. (The database server will send the client a
+"locked" notification at that point to let it know.)
+
+If the client originally obtained the lock through a "steal" request,
+the database server won't automatically reassign it ownership of the
+lock when it later becomes available. To regain ownership, the client
+must "unlock" and then "lock" or "steal" the lock again.
+
+echo
+....
+
+Request object members:
+
+ "method": "echo" required
+ "params": JSON array with any contents required
+ "id": <json-value> required
+
+Response object members:
+
+ "result": same as "params"
+ "error": null
+ "id": the request "id" member
+
+Both the JSON-RPC client and the server must implement this request.
+
+This JSON-RPC request and response can be used to implement connection
+keepalives, by allowing the server to check that the client is still
+there or vice versa.
+
+