Merge pull request #473 from messerc/chris/update-internals-MD

Update INTERNALS to reflect undo/redo removal

INTERNALS.md

@@ -160,7 +160,7 @@ Every change is a JSON object with five properties:
   be declared either.
 * `message`: An optional human-readable "commit message" that describes the
   change in a meaningful way. It is not interpreted by Automerge, only
-  stored for introspection, debugging, undo, and similar purposes.
+  stored for introspection, debugging, and similar purposes.
 * `ops`: An array of operations that are grouped into this change.
 
 Each operation acts on an object, which is identified by a UUID. There are four
@@ -359,7 +359,7 @@ frontend to update its state.
 
 Messages from the frontend to the backend are called **change requests** (as
 they always represent a change made by the local user, via
-`Automerge.{change,undo,redo}`). Messages from the backend to the frontend are
+`Automerge.change`). Messages from the backend to the frontend are
 called **patches** (because they describe a modification that needs to be made
 to the frontend state).
 
@@ -370,18 +370,11 @@ protocol has been implemented on the `performance` branch).**
 ### Change requests
 
 Change requests (sent from frontend to backend) are generated by
-`Frontend.from()`, `Frontend.change()`, `Frontend.emptyChange()`,
-`Frontend.undo()`, or `Frontend.redo()`. Change requests look very similar to
+`Frontend.from()`, `Frontend.change()`, or `Frontend.emptyChange()`. Change requests look very similar to
 changes: they have properties `actor`, `seq`, `deps`, `message`, and `ops` as
 documented above. The difference is that there is one additional property
-`requestType`, whose value must be either `'change'`, `'undo'`, or `'redo'`.
-
-In the case of `'change'`, the other properties describe the change by the local
-user that should be applied to the backend state. In the case of a `requestType`
-of `'undo'` or `'redo'`, the change request does not contain any `ops` property
-(but the other properties `actor`, `seq`, `deps`, and `message` are still
-present). In this case, the list of ops is filled in by the backend (since the
-backend maintains the undo/redo history).
+`requestType`, whose value must be either `'change'` (`'undo'` and `'redo'` are no longer supported as of 1.x). In the case of `'change'`, the other properties describe the change by the local
+user that should be applied to the backend state.
 
 A change request from the frontend is applied to the backend using
 `Backend.applyLocalChange()`, and the backend responds with a patch describing
@@ -405,10 +398,6 @@ A patch is a JSON object with the following properties:
 * `actor` and `seq`: If the patch is a response to a change request, these
   properties are set to match the `actor` and `seq` in the change request.
   Not set on patches generated by `applyChanges()` or `getPatch()`.
-* `canUndo` and `canRedo`: Booleans that indicate whether, after applying this
-  patch, `undo()` and `redo()` should be enabled, respectively. Undo is enabled
-  if there is at least one local change that has not been undone, and redo is
-  enabled if there has been at least one undo since the last change.
 * `clock` and `deps`: Objects in which the keys are actor IDs, and the values
   are the highest sequence number that the backend has processed from that
   actor. The difference between `clock` and `deps` is that `clock` contains all
@@ -530,15 +519,3 @@ that would otherwise have to be computed by iterating over the entire history.
 * `deps`: A map of the same form as `clock`, but excluding transitive
   dependencies — that is, containing only actorID/seqNo pairs that cannot be
   reached through the indirect dependencies of another of the dependencies.
-* `undoPos`: An integer, representing the current place in the undo stack. At
-  any point in time, the first `undoPos` elements of `undoStack` (i.e. indexes
-  0 to undoPos–1) are undoable, and any indexes >= undoPos in `undoStack` have
-  already been undone.
-* `undoStack`: A list of list of operations. One element in the outer list is
-  pushed when a local change is performed through `applyLocalChange()`, and it
-  is set to the list of operations that need to be performed in order to undo
-  that change. Those operations are chosen such that they restore the prior
-  value(s) of any properties that are updated in the course of the local change.
-* `redoStack`: A list of list of operations, similar to `undoStack`. Here, an
-  element is pushed to the outer list when an undo is performed, and it
-  contains the operations that we need to perform in order to undo the undo.