Representation, persistence, state, and usability
When looking at a configuration file, we're looking at a human-friendly version of the state of one or more objects. When we edit a configuration file, we're changing the persistent state of an object that will get reloaded when the application is started (or restarted.) We have two common ways to look at a configuration file:
A mapping or a group of mappings from parameter names to values
A serialized object that's more than a simple mapping
When we try to reduce a configuration file to a mapping, we might be limiting the scope of relationships that may exist within the configuration. In a simple mapping, everything must be referred to by a name, and we have to work through the same key design issues that we looked at in Chapter 10, Storing and Retrieving Objects via Shelve, and Chapter 11, Storing and Retrieving Objects via SQLite, when talking about the keys for shelve and sqlite. We provide a unique name in one part of a configuration so...
