| Stephen Gran on 9 Jan 2008 16:56:57 -0800 |
|
On Wed, Jan 09, 2008 at 03:01:42PM -0500, Matthew Rosewarne said: > On Wednesday 09 January 2008, Stephen Gran wrote: > > > 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? > > This is a widespread practise. You can observe this sort of behaviour in > Debconf, YAST, /usr/sbin/update-*, and all sorts of other applications. This is not the fault of either the storage format or the original application designer. It is the fault of the person who tried to shield you from the complexities of doing something yourself and made it worse. This is not an argument against text files. This is an argument against shielding idiot users. > > > 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. > > This is still often only useful for a user making limited changes to a file > that is otherwise entirely controlled programmatically. It is just not > possible to make this system reliable for anything but the most basic of > editing, such as what you'd see in Debian's /boot/grub/menu.lst > or /etc/mailcap. I'm not sure I understand your point here, so I'll move on. > > > 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 ... > > That's sort of my point, it shouldn't matter to the application how its > configuration info is stored on disk, it just needs its info. Your original point appeared to be that text files were unsuitable because you have to get the daemon to notice the cahnges and reload. Maybe the paragraph I replied to wasn't what you meant? > > > 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 ... > > This is only true if your file is not particularly complicated, as in an INI > file, without any nested structures. When you make a pass with sed through a > more complex config file, you have to hope that you aren't breaking it due to > side-effects from something you didn't expect. If you're doing this all by > hand, it's not a big deal, other than the fact that it takes you a while. If > you're trying to make a program do this in an automated way, you have to take > a more desperate approach, such as declaring certain parts of the config > files as non-editable. > > It's not really relevant that whether you're storing a whole system's > configuration in one file. It's difficult enough even to add a monitor or > mouse to /etc/X11/xorg.conf without discarding the whole thing, which many X > configuration apps do. It's even harder to make some change that might > require changing parts of several different configuration files, such as > changing the port of a service, which would require updating the server > configuration, firewall, forwarding, etc. Ah, I see. You aren't talking about the parser for the program reading the configuration information, you're talking about some hack reading the files to make changes or examine them. That just means the hack is, well, a hack. The only answer to that is "don't do that". Again, this is not a fault of the format. This is the fault of a simple app trying to parse a complicated configuration structure. > > > 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? ... > > Rarely is there a parser available for most configuration files other than the > one built into the application itself, something not easily used by an > external program. And while the syntax may look somewhat similar to a user > for some configuration files, the details of actually understanding and > editing them makes it largely impossible to make one parser for multiple > different files. That's fine. One of the benefits of open source is that people do things in their own to scratch their own itch. Sometimes, a reall ygood idea comes along and a lot of people start using it. We probably wouldn't get that so often if we didn't let people do their own random wierd things all the time. I think this is a good thing. I can see why it might seem a little hard to learn the syntax for the few programs you care about, but *shrug* it's just never been that big a deal in practice. > > > 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. > > Actually, it means using sharing functionality instead of reimplementing it > over and over again for every individual application or config file. If > anything that makes a system far *more* robust and massively reduces > overhead. Think of the difference between using shared libraries vs. > statically linking every single program on your machine, or perhaps even > having every app write their own implementation of open() instead of using > libc. That's a fine idea. The problem, of course, is that all applications are not created equal. App A has exactly 4 knobs to tweak, and they're all on/off. mplayer has 7^27 options, with cascading levels of interdependence and different meanings for some options depending on what came before. Either mplayer has to get a simpler configuration structure that cannot express what it currently can, or App A is going to have some serious bloat to parse 4 options. > > 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. > > I've come across many (well, not *too* many) Windows zealots who don't realise > the strengths of config files and attempt to justify the horrors of the > Windows Registry. Clearly, I'm not in that camp, but I do recognise that > editing configuration files are not the be-all-end-all configuration > interface. I guess it would help me if you told us what it is you propose to use in place of text files. You keep mentioning APIs and even some implementations, but then you discount the actual implementations. So, if we get rid of text files, what would be the on disk format? > > 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 > > Support scripted roll out (no GUI only) > > Well, it wouldn't make sense to make such a system that required SQL, LDAP, or > some other heavy infrastructure. We have enough experience nowadays with > designing a core API that can allow pluggable implementations, for example > the Linux VFS layer. The idea would be to allow one to access the > configuration data by whatever means they choose via pluggable frontends, be > it an LDAP tree, XML file, or directory tree of text files with some sort of > standard syntax, just like an application can open() a file regardless of > whether the underlying filesystem is ext3, XFS, reiser, or whatever else. An LDAP tree or an XML store is generally considered a back end. The application that parses the schema or DTD and presents the data in a normalized manner is the front end. Or am I not understanding what you wrote? > > Does not require more library dependencies (embedded devices) > > Having one implementation of reading/parsing/editing configuration data in one > shared library would save quite a lot of space compared to each app having > its own implementation. It would make small apps much bigger, as above. > > Must reliably keep state across restarts (cannot keep state in RAM, eg) > > Not really much good if you can't reboot the thing, is it? Leaves out cache files in tmp dirs, though. Unless you want cache files in front of text files. > > 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. > > Unfortunately, I'm not aware of any current system that is quite like I > describe, though there are some that are going in the right direction: > > * GConf is implemented in a fairly abominable way, with its own daemon and > special editing tools, though it does have pluggable backends such as XML and > SQL. Yes, it's windows registry fanboyism. > * KConfig is quite a good system, storing its information in an INI-like > format, but using something called the "system configuration cache" (sycoca) > to read the information into a temporary binary cache for a massive > performance boost. The newly-added backend for storing its info in an LDAP > format (be it an LDAP server or Samba's LDB) could become seriously useful > for centrally-managing configuration for a whole network of machines, though > clearly it won't be used much outside of KDE. So, after all the arguing against text files, the system you hold up is .. text files. With an optional cache on the front. Uh huh. -- -------------------------------------------------------------------------- | Stephen Gran | Normal times may possibly be over | | steve@lobefin.net | forever. | | http://www.lobefin.net/~steve | | -------------------------------------------------------------------------- Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|