| Matthew Rosewarne on 9 Jan 2008 19:51:07 -0800 |
|
On Wednesday 09 January 2008, Stephen Gran wrote: > > 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. How could any single person possibly be expected to fully understand every aspect of a modern desktop system? The only reason I have a computer at all is to make my life easier, not give me more work to do. > > 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. I'm trying to say that it doesn't make sense to have an "include" or "user" section of an automatically managed configuration file unless the syntax is extremely simple, since the parser/generator must have a rule for converting anything there into a properly-formed configuration. > 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? I meant more that it is often impossible to alter the configuration of a running program unless it implements a configuration interface of its own. Not being able to alter the configuration on the fly can be a problem if you require minimum downtime for the program, and for each program to implement its own configuration interface would be a massive duplication of effort. There are other aspects to it, but that's the biggest problem. > 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. It should not be a "hack" to alter a system's configuration in an automated fashion, and the fact that it is indicates a problem with the infrastructure. > 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. It's a great thing that people can go out and write something new/better. Requiring that they reinvent something so basic as storing configuration data is an impediment to doing something actually useful, just as it would be if every program had write its own implementation of sockets, for instance. > > 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. I never said this would be easy! Making an interface that is flexible AND lightweight is not something that can be done in a weekend. Aside, I've never been a fan of mplayer's kitchen-sink design, which goes against the essential design principle of separation of concerns. > 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? The point is that it's possible to make it so you *can* use text files, thus recieving the benefit of their robustness, or a binary database if you prefer. What's important is that if you have a standard interface to the data, it doesn't matter how you actually store it, just like how any GUI application can draw on the screen without having to know what model video card you have. > 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? Just like you can make plug-in backends, it's entirely possible to make frontends pluggable. If you have the configuration data in some standard format, you can represent it in whatever form is desired, such as generating an XML file or populating an LDAP tree. > > 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. No, implementating some functionality once and sharing it is going to be smaller than implementing it several times. > Leaves out cache files in tmp dirs, though. Unless you want cache files > in front of text files. I'm not sure I understand, I just meant that you can't really call something a configuration system if it doesn't actually keep that configuration. > > * 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. Well, while Miguel does seem to have a fondness for Redmond, you could also guess that they made GConf that way because it was something familiar. > 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. But that's the whole point. There's no problem with using config files as storage, but rather with using them as the *interface* to the configuration data. 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
|
|