Re: new documents
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
jjorgens@bdsinc.com
Reply to: