Wichert (and all), I've read through your proposal and I've got a few suggestions. Incidentally, I've been thinking about this problem (and dreaming up solutions) for the past month or so. My overall bent is to resolve things down to very cleaning defined components. I think a configuration management/data system is one most suited to small, light-weight components with nice modularity. So, here you go:
1) Decentralize control. I dislike the idea of having a central control file. This file would have to be owned and writable only by root. This makes adding software difficult/impossible for users without root access. Instead, use a CONFIG_PATH variable which would have a list of URLs. Define modules for each type (file:, http:, ldap:) and allow an interface (like PAM with shared libs) which would allow extension of these types. This approach makes things much easier for software testing as well. On the application side, present an interface which would allow programmers to get a variable with a full path 'file:/home/jbj1/configdb' or a simple variable path which would cause the software to iterate through each entry in CONFIG_PATH to find the data. For security and control a fixed path interface will be necessary. One can imagine that something like 'http_server/user/password' would need to be found in fixed, controlled database. On the other hand, I'd like to be able to walk into my local internet cafe and run the email client using my settings from work. 2) Reduce cost of ownership. I can see the value to the debian distribution of all the complicated machinery to make it easier for package maintenance, eg. a link back to the package for each variable, the IsDefault flag, variable meta data, etc. These things are excellent ideas and would prove invaluable to debian developers. However, I would hope that this configuration system would become widespread and adopted by all linux software and distributions. Non-debian users (alas, poor fools) will be put off by extra baggage and seek a different solution fragmenting effort behind a single solution. I'm not saying that these things shouldn't be implemented. Of course they should. However, I believe they should be implemented in another layer above the basic data storage. I believe a basic hierarchical data store similar to the windows registry would be fantastic for almost all software developers. Of course, we need to support more advanced things: a richer set of data types, authentication, encryption, symbolic links. I would even include the IsDefault flag, although I'd call it an 'Archive' or 'Dirty' flag which would simply indicate if the variable had been changed. I believe such a flag would be generally useful and this its inclusion is merited. To implement all the debian package related things a special debian hierarchy. I don't believe the power of the system would be decreased by this approach and this would keep the system easily accessible to all developers. 3) Componentize. Ok, I'm using lots of words that aren't words. Anyway Wichert I see from your proposal that you have in mind a nice clean implementation which will allow each piece to be split up. From the mail I've seen on the list from people very concerned about the system working in X, Gnome, command-line, etc. I sense that things are heading in the wrong direction. If the system is brought into components which are truly reusable this is a non-issue. I would suggest that a C interface be defined for the database. If never done any perl XS stuff or python or anything like that but those that have may wish to suggest conventions which would make things go easier with 'porting' the interface to these languages. I would suggest that at the C interface level there be *no* assumptions about the user interface. For example in the case of authentication we can imagine that the software might try to do a lookup 'https://jens.jens.org/configdb/jens?SET/cards/visa/number' which would cause authentication to be required. Rather than do 'puts("Password: "); fscanf(STDIN, "%s", passwd);' we should use callback functions. This way GUIs could present nice windows to prompt for passwords, command-line apps can use stdio, and apps which can only run in the background can simply fail because no callback was supplied. In addition to the C interface the system would ideally include a few other tools to make things easy for users: an interactive command line interface with shell-like commands to navigate the hierarchies (cd, ls, rm, mv, etc), a batch tool which would read/write a carefully defined file format, and also perhaps a GTK+ app similar to the Windows regedit. Lastly, I wholeheartedly advocate the construction of a mailing list. I really hope that we can develop this system with a lower-level which will not be debian-specific and will make no assumptions about or uses of artifacts of a debian system. That we we can get everyone on board. I offer a machine (a Red Hat box, alas) with fast full-time connectivity and my own time to administer a list if it isn't set up on lists.debian.org. Wichert Akkerman wrote: > I finally got around to updating the configuration management documents > somewhat yesterday. Besides adding the things we have discussed recently > I split the text up into 4 different sections, since the different > modules of the design can very well be used independently. > > The new docs are available at http://www.debian.org/~wakkerma/config6/ > > Wichert. > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature -- Jens B. Jorgensen [EMAIL PROTECTED]