 |
| 1) Identify which classes and methods in the obsolete package are being used. We used five classes: IXStore, IXStoreFile, IXStoreDirectory, IXBTree and IXBTreeCursor and we used most of the public API of those classes. Our data storage model was based on being able to store key-value pairs (with the keys and values being of any size) and to retrieve the values either directly (via the key) or sequentially. 2) Implement those classes and methods. Don't worry about how they "really" work; our goal is to provide functionality without modifying our client code. For example, IXStore was based on the idea of "blocks" of storage; I kept the idea of blocks, but they just became id's used for access into a dictionary. 3) To do the implementation, figure out what you need to do, and look for Foundation Kit classes that will provide provide that functionality. We needed three things: to store key-value pairs to disk and to access those pairs directly (by key value) and sequentially. The Foundation Kit includes NSPPLs (persistent property lists). The NSPPL class description in the Rhapsody Foundation Kit documentation, states: "Like serialization, a persistent property list stores data in a binary format, provides fast access, and is lazy. It also allows you to make incremental changes to an NSPPL (even one that contains tens of megabytes of data), while still ensuring that your data is never corrupted. In this sense, an NSPPL is analogous to a database. Because of their ability to incrementally store and retrieve data, NSPPLs are particularly well-suited for working with large amounts of data (that is, data that has several elements, that occupies a large number of bytes, or both)." |