In cases where the file is written and read by the program, without the expectation that the user will typically edit or read the file by hand, sqlite is someth

In cases where the file is written and read by the program, without the expectation that the user will typically edit or read the file by hand, sqlite is something that should be considered. A sqlite file isn't an ascii text file that you can edit with vi, so that suggestion is likely to get a lot of jeering, but it's a serious suggestion. It's already being used for configuration on all mobile platforms. There exists a wide range of applications, particularly for windows users, where the common user is not a developer and is not meant to be editing configuration by hand. Furthermore, access to the sqlite3 binary is very nearly as widespread as access to a vi binary. And self-styled developers who don't know SQL aside, it actually is a rather convenient format to edit by hand. Machine transformation of the config is obviously straight forward, and sqlite databases tend to be self-documenting anyway. Sane table and row names go a long way (obfuscated tables and rows would be roughly equivalent to obfuscated keys in an ini file...) and if that's not enough, comments for tables and rows can be stored in the schema. The one downside is strictness; sqlite doesn't enforce types. It does however have data constraints, which help.