On Thu, 14 Oct 2004 22:12:51 -0700, Michael A. Peters <mpeters@xxxxxxx> wrote: > That made it a nightmare to maintain the administration utility. > With a database, it is much easier. The value for the setting is > requested from the database, or inserted into the database. It greatly > simplifies how configuration information is stored and retrieved. Specifically... Berkeley DB is an absolutely horrible idea if you need to have multiple people changing multiple settings involving multiple aspects of the system. Can Berkeley DB allow for multiple writes at the same time? There is a price to be paid for centralization into a single embedded database. I'm not extremely keen on the idea of implementing a centralized embedded database for all the system configs from networking to security policy on a system where there are more than one administrator. And since I sort of get the feeling a lot of RHEL deployments are large network, multiple adminstrator sorts of things, I sort of doubt its in the best interest to steer development into the berkeley db direction. And I'm not particularly keen on the idea of requiring moving to heavier multiple user database like postgres to get around the problem of single client writing locks that an embedded database would have. I honestly don't see any gain here at all by over-centralization of disperate subsystem configfiles inside a database. Optional database usage, sure. Requirement, no. > I know people are put off by this because of what MS did with the > registry. But that was MS. Gnome does exactly this - a database for > gnome application settings, gconf - and it works extremely well, and is > a hell of a lot nicer than config files. Cough... i think you misunderstand what Gconf is...and i think you'll find a lively discussion if you care to look about the problems Gconf has had. And frankly I wouldn't be all too shocked if Gconf gets replaced with another attempt at this sort of thing anyways: http://freedesktop.org/Standards/config-spec GConf is NOT an embedded database. Its layer that sits between applications and what could be a number of different configuration storage backends. The commonly used backend isn't a 'database', its a set of xml files. If GConf is the example of the better way to approach the problem, then its not an example supports the argument that you NEED a database backend like db4 at all. You might be able to make a case for structured files like xml instead of flat files, but the case specifically for a centralized berkeley db falls short of the level of discussion thats going to be needed for serious interest compared to previous long thread discussions concerning 'registry' like behavior in the last 6 months. I personally like the discussion pointing to the creation of libconfig that implements an api for the sysconfig flat files instead of more cumbersome solutions like a centralized db as a fedora/redhat sysconfig specific stop gap measure before an appropriate api for config files can be agreed on widely. But even then we get into tradeoffs of how to build files that can be reasonably accessed with and without advanced tools. Don't underestimate the power and flexibility of being able to quickly open up a configuration file in vi from a simplistic rescue environment and be able to get something fixed, in your quest to build a file syntax and layout that is is to build graphical tools on. There are tradeoffs invovled, and I'm not even sure the benefits of even something simple like xml like structured files strikes a balance to the ease of parsing the flat files in vi when its needed. I encourage you to look back to at least July in the archives of this list and read up on similar discussions. -jef
