Date: Thu, 13 Feb 2003 12:05:06 -0000 From: "Paul Robinson" <paul@iconoplex.co.uk> To: <arch@FreeBSD.ORG> Subject: RE: syslog.conf syntax change (multiple program/host specifications) Message-ID: <IPEDKJGCDFHOPEFKLIDHKEENCCAA.paul@iconoplex.co.uk> In-Reply-To: <20030213122218.3d72c6ba.Alexander@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander wrote: > How do you want to solve the problem of: > - T1: a human edited /etc/rc.conf without updating the .xml > - T2: someone else (or the same human) uses the GUI to change something > --> the hand edited change in rc.conf is lost Oh, that's easy. What you do to keep two views of the same information consistent, is keep all the data in an SQL database, and then just software that pulls the information out into the two different formats, and pushes the data back in on changes! So, what we do is put all the config information into mySQL and insist it ships as standard on every box! :-) On a more serious note, the only way this system would work completely is if there were some trigger mechanism after editing the file. I suppose something like the new aliases stuff under sendmail would have to be implemented. At that point, I think a lot of users would ask "what's the point?" XML is great for lots of things. It means my web server can interact with a customer database on an AS/400 with about half a day's work. It means that documents that should be in a standard non-proprietary format, like music scores for example, are indeed put into standard non-proprietary formats. For these things, and others, XML quite frankly, rocks. Unfortunately, it sucks for configuration files on Unix machines. It would be great for configs on Windows machines or Mac OS, because nobody ever manually plays with the files. I hate to play the pedant on this one, but as a last point, this might serve as a good reminder as to why XML is a bad idea in the framework of FreeBSD: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/introdu ction-archguide.html The first, sixth and seventh points seem to apply here. I'm not going to start a whole new flamewar as to whether these guidelines should be upheld or not, but they do make sense and particularly relevant in my mind to this discussion. Just my ?0.02 worth. I'll go away and shut up now. -- Paul Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?IPEDKJGCDFHOPEFKLIDHKEENCCAA.paul>