Major components:

• Slot value storage (on disk hash or just btree?)
• Btree Library
• Transaction Management
• Support for garbage collection?
• Multidimensional indexing such as Bkd-trees or R-trees?
• Persistent heap?

Design tradeoffs:

Slot value storage issues:

• Do we lock individual slot values (like the BDB data store) or entire class objects?
• Do we use a hashing model, or just reuse the Btree library?

Btree library: binary fixed-size page approach vs. using and serializing a lisp Btree node object

• Messing with binary pages adds complexity but probably saves effort.
• If we use lisp structures for the BTree node (an alist, for example) then we don't know the size of a node until it is serialized at which time we may have to move it or split it up. Maybe this is fine.
• If we design the abstraction right, we could start with one and move to the other.

Transaction management:

• Fine-grained locking model vs. optimistic concurrency (versioned objects ala Rucksack?)
• Does our solution involve deadlocks? How to unwind?

Multi-process support:

• Centralized server or replication?
• Distributed transactions?

Transactional block-store layer: What about a layer of the program that handles reading/writing to disk, transactions, and multi-process/-machine support. This layer could exist as a separate library and building efficient Btree/heap/hash/etc. persistent data structures would be a separate matter. The main transactional grunt work would be done by the block store and could be reused for other projects. --rdaly