I think I’m glad I don’t read Raymond’s posts. There is another point about binary speed that I thought I should bring up. Some programs rely on text files for configuration, but then compile them before use. sendmail and postfix are good examples of programs that do this with their use of map files like “aliases”. This nicely handles transaction level issues too. PHP developers use caching to the same effect as well. Edit code, flush cache to see changes and get compiled speed.

There is another text file format that I’ve recently discovered called YAML (YAML Ain’t Markup Language):
http://www.yaml.org/spec/1.1/

It has all of the benefits of XML without the XML.

As for Java, it not mandatory. It only really concerns Java classes that will be distributed as a library, where the risk of namespace collision is possible. That said, it would certainly be nice if you could collapse some of the unnecessary hierarchy. Something like “edu.usc.ict/saso/nlu/..” or even “edu.usc.ict.saso/nlu/..”. For the purposes of the compiler and compile-in-place development directories, this should not be an significant issue, as the ‘.’ character has a specific meaning in a Java identifier. The extra test to find the correct path (com.example/.. or com/example/..) shouldn’t cost much in a single compile, and could even be cached between compile iterations. After all, a degree of guess and check is already implemented as each entry of a classpath is tested. I would not recommend this convenience inside JAR files, and definitely not on raw .class files across http (who does that anymore anyway?).

It is used to prevent namespace collisions by relying on a shared name authority. Reversing it keeps related entries grouped together when sorted alphabetically. In contrast, Microsoft’s registry relies on the statistically unique UUID, which is anything but human readable or intelligently sorted. Give me reverse domains over that any day.

Here’s a quote from the comments that mentions plists as well:

“Apple has an elegant solution, .plist files are basically XML files but can also be in a binary format, there is a command-line utility called ‘plutil’ that can convert them from binary to human readable and vice versa (there is also a GUI editor). Applications using these plist files (through the appropriate API’s) can use both types transparently. If you want to tweak something, just convert it to human readable, and when done tweaking return it to binary if you prefer.”

Inside these directories are reverse-domain-named .plist files. Plist stands for “property list”, and it is effectively a XML structure file (modified from the original NextStep plist test files). The structure provides Unicode strings, numbers, dates, and even arrays and dictionaries.

That said, the current recommendation is a binary version of this, addressing the parsing speed issue. But fear not, apple open sourced their libraries for handling plists (as part of the BSD licensed Darwin source release) and their binary counterparts. Not only does this provide a standard interface for accessing the files, but it has lead to many automated and GUI tools for manipulating .plist files.

So to address Raymonds complaints of INI files:
* We get Unicode and structured data.
* Security granularity is provided by different .plist files, and more specifically, standard locations for common security permissions.
Additionally, we have a standard location that is something other than ~/.app/ or ~/.apprc (stupid Unix).

In theory, we have the threading problems with writing data and locking files, but these are generally a good thing. I don’t believe Windows registry is transactional, so I cannot write multiple related keys without risking another app will read a partial state. Grouping data by .plist files implicitly provides that transactional security. Of course this leads to potential denial of service, but the separation of system and user preferences, and the use of different files per application / library, means that the effects are minimized unless you have more widespread problems (e.g., malicious programs with Admin priviledges).

I will say that some applications side-step the .plist format (usually in favor of some legacy format), but at least they still use directories within the ~/Library/Preferences directory. I still know exactly what to back up and exactly where to look if I need to repair / wipe an app’s preferences.