On Sun, 13 Jan 2002, Donovan Baarda wrote: [SNIP] > Note that backwards compatability with existing config files has lead to the > /etc directory changing roles. Once upon a time this dir contained files > that admins edited directly. Increasingly, editing these files directly is > becoming "not the right way to do it", with tools like adduser and > update-<somethingoranother>, becoming the new admin interface. I don't know > if these are helping much becase these tools themselves are not that > consistant. The /etc directory is becoming like an add-hock config database > with a mish-mash of storage formats and multiple inconsistant access API's.
True. The problem with a lot of unix configuration files is that they were intended to only be *read* by the programs that use them, not *written*. And that still shows in their format, which is generally much easier to read than to update in an automated fashion. Also, a difficulty with line-oriented ASCII files is that their records have variable length, and updating such records is relatively hard. This of course stems from the fact that Unix only offers files as streams, not records - which is generally a good thing, IMHO, but it makes things a bit cumbersome in this case. The next problem is the general problem of different programs communicating together. If the program or package to which a configuration file belongs does not implement write support, and changing a configuration is done by a different program, then the configuration effectively file becomes a protocol. Sadly, most formats were not exactly designed with the robustness of a real protocol in mind. Defining a standard presentation for configuration data, so that readers and writers at least agree on syntax, is not a bad idea, I think. Of course, as with a real protocol, it should be relatively easy to write implementations. To *require* a particular library or API because implementation is complex will cause it to become an evolutionary dead end at some point. I definitely don't think we should have a fragile, binary heap of pointers - a filesystem-on-a-filesystem like the windows registry does *not* seem to be a good idea. Lots of small real files are not the fastest thing in the world on most Unix filesystems though, so it seems we need some compromise until everybody starts using ReiserFS or something like that. But again, I'd definitely object to having the whole configuration tree in a single file. That would be wasting a perfectly good hierarchical DB already offered by Unix - the filesystem. The modern cron.d / modutils / ip-up.d etc. approach over single files shows how much write support can already be made much easier by taking advantage of it. Perhaps DBM or something similar, like djb's cdb format could be an option. Using a separate file per 'table' lowers the risk of binary files a bit, and the filesystem could be used to store these tables in a nice hierarchical fashion. It's not that ideal perhaps, but IMHO better than a windows registry, XML or even LDAP. The latter is a nice idea, but I really think the configuration hierarchy should be reflected in the unix filesystem, not hidden inside a database. I'd like to manage data by simply copying it around, using tar, rsync, etc. In any case, I really think that this problem should be approached as designing a protocol: put the smarts in the data, not the code; make it robust and extensible, and easy to implement support for - from scratch if needed. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153 | http://www.xs4all.nl/~evbergen/