Re: Configuration file design

Which is/would be a more typing for the user, and thus more to get wrong..

This isn't always a bad thing ... in fact, it's frequently a good thing.

By having a format with a little extra markup, you help reduce the number of missunderstandings about what was intended. In simple formats (like KEY=VAL) how does a person represent a value with a newline in it? or what about a key with an equals sign in it ... or a space?

The user might try these things, and your program might run just fine without any errors, because what they've given you is a valid file, it just may not be valid in the way they think it is. By having a few mandatory requirements that require a little additional typing, you can help ensure that there isn't any confusion.

Your INI file approach already does a little of this ... assuming you are validating that the only sections in the file are [main] and [ftpNN] where NN appears in the list of ftp_instances, and that everything in the list has a section -- that way you reduce the risk that they add an [ftp99] section without adding it to the list. But you should also worry about the possiblity of duplicate sections (happens a lot when people cut/paste key/val pairs and change the value but forget to change the key)

The biggest downside to an INI type solution is that it does require them to duplicate data ... you could avoid that by saying that the set of sections determines the number of FTP hosts, and eliminate the "ftp_instances" list completely -- but that's probably not very practical if you want to have lots of sections for lots of sets of config info.

Which is where XML style config files come in handy ... the biggest complaint against XML configs is duplicate markup; but nestability, quoting, and DTDs make it a really great choice to eliminate confusion and identify mistakes...

<config>
  <root>/path/to/root</root>
  <files>/path/to/files</files>
  <ftps>
     <instance id="00">
       <source>/blah/path/blah</source>
       <save>/blah/path/blah</save>
     </instance>
     <instance id="01">
       <source>/blah/path/blah</source>
       <save>/blah/path/blah</save>
     </instance>
     ...
  </ftps>
</config>
[download]

Comment on Re: Configuration file design Select or Download Code

Replies are listed 'Best First'.
Re^2: Configuration file design by Corion (Patriarch) on Jan 04, 2005 at 09:45 UTC
Sorry, but if you have to make manual changes to such a file, and have a non-XML-competent user, this will become really ugly. You can't "phone in" any changes to such a file, and there is far too much unnecessary fluff that clutters the relevant data - you can't easily put a whole section into comments unless you use the XML comments, which will lead to confusion regarding which section is active or inactive.	[reply]
Re^2: Configuration file design by castaway (Parson) on Jan 04, 2005 at 10:09 UTC
Hmm, sorry, I disagree. The XML looks even worse for a human to edit, sure, its readable, but to create by hand? Yuck. OTOH you did give me another idea: The one with leaving out the ftp_instances variable, and just getting the user to give information for each ftp instance. I can create the value of ftp_instances dynamically, the IDs too, since they just need to be unique. Another way to do it would be to have variables with a list of values for each ftp_instance variable, but I think that's uglier: `hostnames=one,two,three sourcepaths=/path/one,/path/two,/path/three` [download] (and less usable) As for your other concerns, the variables can't contain newlines, the split only splits on the first '=' and variable names cant contain an '=' or a space. (These are unix environment vars, so I'd be quite surprised if that even worked, the config files contain mostly a bunch of "export VAR=X", anyway, even if it was possible, this software doesn't have any). These won't be idiots, that will be running this, after all, they usually install the software by editing all of it's config files, and getting them lined up with each other. I'm just trying to make the process easier, without making it more complex in the process. Duplicating data is not a bad thing, if it provides more clarity.. IMO C.	[reply] [d/l]