NSPPL: Persistent Property Lists
David Smith notes that in 1998 Apple removed the NSPPL class from Foundation and open-sourced it. Today, property lists can be serialized in XML and binary formats. In both cases, these are chunks of data that are read and written atomically. The old NeXT system supported ASCII plists as well as a lazy binary format and a persistent property list (PPL) format that supported incremental access and caching in memory:
You can store a property list in three different ways: as an ASCII file, in a serialized binary format, and as a persistent property list (PPL). Each of these approaches has its advantages. For example, an ASCII property list is human-readable, but access is slow. Serialization, which stores property lists in a binary format, offers faster access than an ASCII property list and it’s also lazy, meaning that you can read parts of files without accessing the whole thing. But serialization doesn’t allow you to modify your data and then only re-serialize the part that changed.
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 PPL (even one that contains tens of megabytes of data), while still ensuring that your data is never corrupted. In this sense, an PPL is analogous to a database. Because of their ability to incrementally store and retrieve data, PPLs 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).
After creating an NSPPL, you could read or write to it by using the -rootDictionary method to get a mutable dictionary proxy object (with its own lazy NSEnumerator).
Persistent property lists are atomic, meaning that if a save operation fails, the PPL reverts to its previously saved state. An PPL is never left in an intermediate state. Changes to an PPL are applied incrementally (in memory, but not to disk) as you make them and are reflected in the
storeandlogfiles. Asaveoperation has the effect of committing the changes you’ve made to disk.
The file extension for the store was .ppl, and there was a ppl command-line tool for converting between persistent and ASCII property lists.
1 Comment RSS · Twitter
I had a look to see if I could learn anything from the code, but it's not easy to wrap your head around the implementation, especially since all of the private helper classes are all declared and implemented in the .m file (it must be tough to be a framework developer).
With all of the different types of objects you can store in a plist, it looks like it uses a class cluster pattern.
I wonder if that there was another file documenting the ideas behind implementation that was not included in the source.
