Stephen Gran on 9 Jan 2008 05:12:57 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Config Files (Was: Sharing an Internet Connection)

On Tue, Jan 08, 2008 at 09:28:43PM -0500, Matthew Rosewarne said:
> I'm sure I won't get any friends for saying it, but config files are a 
> terrible interface (the important word!) to configuring systems in many 
> common situations.

There isn't anything better.

> From the point of view of a developer or someone administering multiple 
> systems, configuration files provide a largely insurmountable challenge.
> 1. Configuration files are extremely difficult to edit programmatically.  Many 
> applications get around this by simply writing "DO NOT EDIT!" somewhere in 
> the file or having an extremely limited syntax.  Placing such restrictions on 
> config files negates any benefit from being able to edit them manually.

This is not my experience - are you thinking of auto generated config
files which have parsers that are fragile?

> 2. Configuration files are not very granular.  This makes it extremely 
> difficult to propagate changes to parts of a configuration without 
> overwriting the whole thing, which is an enormous obstacle to managing 
> multiple machines or editing a configuration programmatically.

Many parsers now support the equivalent of include.  For those that
don't, it's still fairly easy to target a change at a block of a file.

> 3. When a user modifies a configuration file, the program is typically not 
> aware of the changes.  While this may be useful in some situations, most of 
> the time this would involve restarting the program and hoping the changes 
> don't cause it to barf.  In a high-uptime environment, this is problematic.  
> It also makes it far more difficult to have hooks run when certain values are 
> changed.

This is the same no matter what your storage medium is for
configuration.  The running software needs to notice that the
configuration has changed, reread it, validate it, and start using it.
It really doesn't matter how you store it on disk.

> 4. Text files are slow and unwieldy for applications to read or write.  A 
> configuration file must often be parsed in its entirety in order for any of 
> its information to be extracted.  Similarly, they usually must be written out 
> fully for any changes to be saved.  While it might be possible to get around 
> this with regex magic, it still requires parsing the entire file and is 
> likely to break.

Text files are actually very good - you can do linear seeks through the
whole file, and do validation at the end.  If you are only interested in
extracting tiny bits out of a monolithic file, some sort of indexed
storage would be preferable, of course.  That sort of approach is
usually unnecessary though - I actually want apache to reread it's
entire configuration to make sure nothing else has changed.  the only
time you need to extract one bit from a configuration store instead of
the whole thing is when you store all programs configuration information
in the same store.  In which case you've got the Windows registry, or
you're sufficiently silly that you've reinvented it (gconf, I'm looking
at you).

> 5. Just about every configuration file has a different syntax.  Not only does 
> this mean that users must learn all sorts of different syntaxes to manage 
> their systems, but that a different parser program must be written for every 
> individual file.  Often this results in a scenario like that of TeX, where 
> there is only one parser implementation capable of fully understanding the 
> contents of a file.

Is this actually important in practice?  Most programs are actually
converging on several of the big configuration styles (apache, ini,
etc).  The parser for the config file is presumably aready written by
the time you start running the program, so this isn't actually a
downside.  The only hard part is that users might need to get used to
another format.  File a bug that they should use one of the existing
standard formats, if that bothers you.

> There are other issues, but those are the most important ones I can think of 
> off the top of my mind.  I'm certainly not going to claim that an approach 
> like the accursed Windows Registry is superior, it's terrible.  The best 
> option I can think of would be a flexible configuration _interface_ 
> (by "interface" think "API" rather than "GUI") that could be viewed/edited as 
> a text file, or maybe an XML file, or even an LDAP tree, with the actual 
> storage being handled out of sight.  I would hope that something such as the 
> Elektra Initiative would come into fruition and gain more widespread use, 
> giving us Free software users the best of all possible options.

All of the options you're discussing mean that a running system's
configuration depends on bigger and bigger layers of abstraction and
additional support, making any given service more fragile.  It also mean
more overhead for running a given service, making things like openmoko
quite a bit harder.

Sorry to argue quite so strenuously, but I feel you really haven't made
a case for any alternative, and I've now seen this same attitude crop up
in a few places in the last few days.  I am curious what (aside from "I
hate having to remember the syntax for $program") is motivating this.

So, if you want to convince me that text files should be replaced with
something else, go ahead.  This is what I think a good configuration
system should be:

does not rely on any network services (SQL, LDAP, etc) 
Human editable in case of disaster
Does not require more library dependencies (embedded devices)
Support scripted roll out (no GUI only)
Must reliably keep state across restarts (cannot keep state in RAM, eg)

And maybe I'm some others, but that's probably a good start.
If you can suggest something better than text that meets those, lets
talk about it.
|  Stephen Gran                  | All right, you degenerates!  I want     |
|             | this place evacuated in 20 seconds!     |
| |                                         |

Attachment: signature.asc
Description: Digital signature

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --