On the same idea as Nagios and your crack at /etc/hosts et al, I've already taken the preprocessor approach for hosts, netgroup, dhcpd and named files for our departmental machines. Like the benefits you mentioned for Nagios, the existing system could be left as-is, but you allow people to use a possibly easier format or tools to edit the file. I think that yum could also benefit from the preprocessor approach, especially if more and more additions are being made. There is, of course, no reason that users wouldn't be able to choose between using the older format or the new. -- Wayne || From Carroll, Jim P [Contractor]: || || To take another cut on this, perhaps the format of /etc/hosts, || /etc/passwd, /etc/shadow and so on should be changed to XML. || And everything which interfaces with those files changed to suit. || || Yes, this was an attempt at reductio ad absurdum. ;) || || >From another perspective, let me submit the following. I'm on the || nagios-users (www.nagios.org) mailing list. There have already || been a few discussions encouraging the author to rewrite Nagios || so that the config files are in XML. Because of the modular || nature of Nagios, the "path of least resistance" option which || seemed to rise to the top, was one of letting someone write || a preprocessor. This preprocessor would parse XML files and || produce native Nagios config files. This has 2 benefits: it || allows the core developers to continue working on Nagios without || getting sidetracked, and it will (eventually) allow XML || folks to work within their familiar domain. || || The yum project doesn't appear (to me) to be on the same level || of development complexity as Nagios, so the preprocessor approach || might not be appropriate. I only make the suggestion as an alternative || to help resolve the "less filling" vs. "tastes great" debate. ;)
