Added more to the article

diff --git a/article.pod b/article.pod
index 5441cef..c4bc33d 100644 (file)
--- a/article.pod
+++ b/article.pod
@@ -34,6 +34,62 @@ And, with the release of 1.00, there is now a fourth reason -
 software-transactional memory, or STM
 (L<http://en.wikipedia.org/wiki/Software_transactional_memory>).
 
+=head1 How does DBM::Deep work?
+
+L<DBM::Deep|DBM::Deep> works by tying a variable to a file on disk. Every
+single read and write go to the file and modify the file immediately. To
+represent Perl's hashes and arrays, a record-based file format is used. There
+is a file header storing file-wide values, such as the size of the internal
+file pointers.  Afterwards, there are the data records.
+
+=head2 DBM::Deep's file structure
+
+L<DBM::Deep|DBM::Deep>'s file structure is a record-based structure. The key (or array
+index - arrays are currently just funny hashes internally) is hashed using MD5
+and then stored in a cascade of Index and Bucketlist records. The bucketlist
+record stores the actual key string and pointers to where the data records are
+stored. The data records themselves are one of Null, Scalar, or Reference.
+Null represents an I<undef>, Scalar represents a string (numbers are
+stringified for simplicity) and are allocated in 256byte chunks.  References
+represent an array or hash reference and contains a pointer to an Index and
+Bucketlist cascade of its own.
+
+=head2 DBM::Deep's class hierarchy
+
+Managing all of these functions takes a lot of different abstractions. There
+are at least 3 different interfacing layers, and more if you look hard enough.
+To manage this complexity, L<DBM::Deep|DBM::Deep> uses the following abstractions:
+
+=over 4
+
+=item * Tying classes
+
+These are the classes that manage the external face of the module. They manage
+B<all> of the interactions with outside code - OO interface, tying, and
+various utility methods. If they cannot handle the request themselves, they
+delegate to the engine. There are currently three classes in this layer.
+
+=item * Engine classes
+
+These classes manage the file format and all of the ways that the records
+interact with each other. Nearly every call will make requests to the File
+class for reading and/or writing data to the file. There are currently nine
+classes in this layer.
+
+=item * File class
+
+This class mediates all interaction with the file system. Every read, write,
+lock, and unlock goes through this class. There is currently one class in this
+layer.
+
+=item * Iterator classes
+
+These are introspection classes that provide iteration for hashes. They manage
+keeping track of where the next key should be and how to get there. There are
+currently four classes in this layer.
+
+=back
+
 =head1 What are transactions?
 
 Originally from the database world, a transaction is a way of isolating the
@@ -122,18 +178,6 @@ means that transactional information should be stored in the keys. This means
 that the entire datafile is unaware of anything to do with transactions, except
 for the key's data structure within the bucket.
 
-=head2 DBM::Deep's file structure
-
-L<DBM::Deep|DBM::Deep>'s file structure is a record-based structure. The key (or array
-index - arrays are currently just funny hashes internally) is hashed using MD5
-and then stored in a cascade of Index and Bucketlist records. The bucketlist
-record stores the actual key string and pointers to where the data records are
-stored. The data records themselves are one of Null, Scalar, or Reference.
-Null represents an I<undef>, Scalar represents a string (numbers are
-stringified for simplicity) and are allocated in 256byte chunks.  References
-represent an array or hash reference and contains a pointer to an Index and
-Bucketlist cascade of its own.
-
 =head2 Transactions in the keys
 
 The first pass was to expand the Bucketlist sector to go from a simple key /