 # comparator. The extractor is used to extract a key from the stored record. The
 # comparator is used to order records by comparing the key.
 #
-# Separating extraction from comparison allows us to cache the key.
-#
-# Keys are relevant even when the record itself is not of interest to the
-# application developer. Keys are used to order the tree, so when we will
-# constantly be reading records off the disk solely to get their key value.  If
-# we don't need the actual record, it will eventually be collected by a cache
-# purge, while the key will be retained. If the key is subset of a large record,
-# purging the records and retaining the keys will reduce the in memory size of
-# the b&#x2011;tree.
-#
-# Also, the comparator is pretty easily generalized, while the exractor
-# is invariably specialized. You might have a single string comparator that you
-# use with many different extractors.
+# Separating extraction from comparison allows us to cache the key. We do not
+# need the whole record for comparison, only the key. Keys are used to order the
+# tree, so when we will constantly be reading records off the disk solely to get
+# their key value.
+#
+# If a record is read for its key, but the record is not soon visited by a
+# cursor, it will eventually be collected by a cache purge, while the key will
+# be retained, if the key is frequently consulted by queries as they descend the
+# tree. If the key is subset of a large record, purging the records and
+# retaining the keys will reduce the in&#x2011;memory size of the b&#x2011;tree.
+#
+# Also, the comparator is pretty easily generalized, while the exractor is
+# invariably specialized. You might have a single string comparator that you use
+# with extractors specialized for different types of records.
 #
 # ### Default Collation
 #
 # You will almost certainly define your down extractors and comparators, but the
-# b&#x2011;tree has a default that works for b&#x2011;tree that stores only JavaScript primitives.
+# b&#x2011;tree has a default that works for b&#x2011;tree that stores only
+# JavaScript primitives.
 
 # Default comparator is good only for strings, use a - b for numbers.
 comparator = (a, b) ->

# Strata is a b&#x2011;tree. A b&#x2011;tree is a database primiative. Using
# Strata, you can start to experiment with database designs of your own. You can
# use Strata to build an MVCC database table, like PostgreSQL. You can create
# Strata b&#x2011;trees to create relationship indexes. You can use Strata to
# store what ever form of JSON suits your needs like NoSQL databases.
#
# Strata is two database primatives in one, because with a time series index,
# you can use Strata as a write ahead-log.
#
# Strata runs anywhere that Node.js runs, in pure JavaScript.
#
# TK Transition.
#
# ## Terminology
#
# We refer to the nodes in our b&#x2011;tree as *pages*. The term node conjures an
# image of a discrete component in a linked data structure that contains one,
# maybe two or three, values. Nodes in a b&#x2011;tree contain hundreds or thousands of
# values. They are indexed. They are read from disk. They are allowed to fall
# out of memory when they have not been recently referenced. These are behaviors
# that conjure an image of a page of values.
#
# Otherwise, we use common teriminology for *height*, *depth*, *parent*,
# *child*, *split* and *merge*.
#
# There is no hard and fast definition for all the terms. A leaf is a fuzzy
# concept in b&#x2011;tree literature, for example. We call a page that contains
# records a *leaf page*. We call a non-leaf page a *branch page*. The term
# *order* means different things to different people.  We define the order of a
# branch page to be the maximum number of child pages, while the order of a leaf
# page to be the maximum number of records.
#
# The term *b&#x2011;tree* itself may not be correct. There are different names for
# b&#x2011;tree that reflect the variations of implementation, but those distinctions
# have blurred over the years. Our implemenation may be considered a b+tree,
# since pages are linked, and records are stored only in the leaves.
#
# Terms specific to our implementation will be introduced as they are
# encountered in the document. 

# Branch pages contain links to other pages, and do not store records
# themselves.
#
# Leaf pages are linked in ascending order to simply the implementatoin of
# traversal by cursors. Branch pages are singly linked in ascending order to
# simplify implementation of branch page merges.
#
# The order of a branch page is the maximum number of children for a branch
# page. The order of a leaf page is maximum number of records for a leaf page.
