Application configuration files [closed]

Answer 1

I think the only important thing is to choose a format that you prefer and can navigate quickly. XML and JSON are both fine formats for configs and are widely supported--technical implementation isn't at the crux of the issue, methinks. It's 100% about what makes the task of config files easier for you.

I have started using JSON, because I work quite a bit with it as a data transport format, and the serializers make it easy to load into any development framework. I find JSON easier to read than XML, which makes handling multiple services, each using a config file that is modified quite frequently, that much easer for me!

Answer 2

As far as I know, the Windows registry is no longer the preferred way of storing configuration if you are using .NET - most applications now make use of System.Configuration [1, 2]. Since this is also XML based it seems to be that everything is moving in the direction of using XML for configuration.

If you want to stay cross-platform I would say that using some sort of a text file would be the best route to go. As for the formatting of said file, you might want to take into account if a human is going to be manipulating it or not. XML seems to be a bit more friendly to manual manipulation than INI files due to the visible structure of the file.

As for the angle bracket tax - I don't worry about it too often as the XML libraries take care of abstracting it. The only time it might be a consideration is if you have very little storage space to work with and every byte counts.

[1] System.Configuration Namespace - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] Using Application Configuration Files in .NET - http://www.developer.com/net/net/article.php/3396111

Answer 3

Re: epatel's comment

I think the original question was asking about application configuration that an admin would be doing, not just storing user preferences. The suggestions you gave seem more for user prefs than application config, and aren't usually something that the user would ever deal with directly (the app should provide the configuration options in the UI, and then update the files). I really hope you'd never make the user have to view/edit the Registry. :)

As for the actual question, I'd say XML is probably OK, as plenty of people will be used to using that for configuration. As long as you organize the configuration values in an easy to use manner then the "angle bracket tax" shouldn't be too bad.

Answer 4

First: This is a really big debate issue, not a quick Q+A.

My favourite right now is to simply include Lua, because

• I can permit things like width=height*(1+1/3)
• I can make custom functions available
• I can forbid anything else. (impossible in, for instance, Python (including pickles.))
• I'll probably want a scripting language somewhere else in the project anyway.

Another option, if there's a lot of data is to use sqlite3, because they're right to claim

• Small.
• Fast.
• Reliable.

Choose any three.

To which I would like to add:

• backups are a snap. (just copy the db file.)
• easier to switch to another db, ODBC, whatever. (than it is from fugly-file)

But again, this is a bigger issue. A "big" answer to this probably involves some kind of feature matrix or list of situations like:

Amount of data, or short runtime

• For large amounts of data, you might want efficient storage, like a db.
• For short runs (often), you might want something that you don't need to do a lot of parsing for, consider something that can be mmap:ed in directly.

What does the configuration relate to?

• Host:
  • I like YAML in /etc. Is that reimplemented in windows?
• User:
  • Do you permit users to edit config with text editor?
  • Should it be centrally manageable? Registry / gconf / remote db?
  • May the user have several different profiles?
• Project:
  • File(s) in project directory? (Version control usually follows this model...)

Complexity

• Are there only a few flat values? Consider YAML.
• Is the data nested, or dependent in some way? (This is where it gets interesting.)
• Might it be a desirable feature to permit some form of scripting?
• Templates can be viewed as a kind of configuration files..

Answer 5

YAML, for the simple reason that it makes for very readable configuration files compared to XML.

XML:

<user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx">ahunter@example1.com</address>
    <address password="xxxx">babooey@example2.com</address>
</user>

YAML:

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: babooey@example1.com
              password: xxxx
            - address: babooey@example2.com
              password: xxxx

The examples were taken from this page: http://www.kuro5hin.org/story/2004/10/29/14225/062

Answer 6

If your configuration file is write-once, read-only-at-bootup, and your data is a bunch of name value pairs, your best choice is the one your developer can get working first.

If your data is a bit more complicated, with nesting etc, you are probably better off with YAML, XML, or SQLite.

If you need nested data and/or the ability to query the configuration data after bootup, use XML or SQLite. Both have pretty good query languages (XPATH and SQL) for structured/nested data.

If your configuration data is highly normalized (e.g. 5th normal form) you are better off with SQLite because SQL is better for dealing with highly normalized data.

If you are planning to write to the configuration data set during program operation, then you are better off going with SQLite. For example, if you are downloading configuration data from another computer, or if you are basing future program execution decisions on data collected in previous program execution. SQLite implements a very robust data storage engine that is extremely difficult to corrupt when you have power outages or programs that are hung in an inconsistent state due to errors. Corruptible data leads to high field support costs, and SQLite will do much better than any home-grown solution or even popular libraries around XML or YAML.

Check out my page for more information on SQLite.