Argthtjtr

I've noticed that tons of programs store configuration info in various hierarchial keys. For example, Firefox's about:config has keys like network.http.pipelining and network.http.pipelining.ssl and network.http.use-cache. I've noticed this style of configuration in Firefox, in OS X (Library/Preferences), in sysctl, among others. Why is it so common? Was there some early program that used it, so others copied it?

This hierarchical convention is there to provide clarity, helping us to know the scope of influence of each settings and to differentiate multiple settings with an identical or ambiguous name among various modules.

This is useful in applications with too many possible settings to include in the main user option pages (where the hierarchy is shown by tabs or pages), and a good alternative to plain INI files (with [title] section delimiters) that are more prone to user error and usually require an application restart to take effect.

Hierarchal settings are also likely to reflect, to an extent, the internal top-down object-oriented model used by the developers:

In this example model, we could very well imagine a person.professor.disallow_strikes = true setting in there, while a students.disallow_strikes could remain to false or not be available at all. This compartmentalization is also the basis for Namespaces in programming languages (and the popular .NET framework follow the exact same naming convention: using System.Threading.Tasks).

So, we now can assume that network.http.xxx setting should not have influence on network.ftp or other network submodules, while a network.xxx setting will likely have influence on all of them.

The extra information is beneficial...

• for the user: we have a better idea of which part of the application a given setting will have influence, making problems easier to troubleshoot (and avoid!)




• and for the developers: the person working on or troubleshooting a specific module can be easily aware of which user-modifiable setting can affect his/her current work and concentrate on that.

You've mentioned one of the main reasons in your opening sentence: hierarchical keys.

Each group of keys is, uh, grouped. All the network related keys are network.something. All the http related keys are network.http.something and so on. This makes the key itself somewhat self-documenting what the value refers to. If one were to use the ini file style (which, to be clear, nothing would stop you from using these sorts of keys if you wanted) with [section] and key=value pairs, a given key may be ambiguous until the section is known. More over, the placement of keys in a file is important. Putting the ssl key in the [GUI] section is probably a mistake and may cause the key to be ignored. The a.b.c style should mean the order of keys in a file doesn't matter. If you read networking.http.ssl.key= it doesn't matter if the previous line was gui.background.color= or something else. The fully qualified key is named.

Why is it so common? It's bloody useful, that's why. It's also easy for humans to read and understand (on a key by key basis) and edit.

Where did it come from? I'd say C style structures which probably have a lineage I'm unaware of, and which have trickled down into many other programming languages as well. Setting a value in a C structure would be structure.property=value, and for nested structures structure.substructure.property=value and so on (though in real life, pointers would translate many of those dots into -> instead, but that's a minor trifle).