Wichert Akkerman wrote: > * all proposals for a file with the variable list share 1 thing: the priority > of a variable is given in this list. I don't think that is reasonable > though: > we can't always know if a variable is important until we know the > conditions. > For example: if you configure sendmail as a nullclient, it is critical to > know the smarthost. In all other situations knowning the smarthost is not > important at all.
I think we should at least have a default priority. > 2. Types of variables > Multiple types of variables can be stored in the configuration space. A > preliminary list of types is: strings, numbers, lists, hostnames, IP > addresses. Each variable can have meta-data associated with it for special > purposes. The minimum meta-data associated with a variable is: long and short > description, type, default value and an `isdefault' flag. The `isdefault' > flag > states if a variable has been changed from it's default value. This can be > used > when upgrading a package to check if the user has changed the default, or it's > safe to change it to a new default. This gives us the same result as the > md5sum-checking dpkg does for conffiles, but on a much finer-grained level > (per > variable instead of per file). I see you've added "isdefault" back. It is unncessary, because we have a default value now. It's simple to compare the default value with the current value to see if the value has changed, therefore an "isdefault" flag is superflous. > (This format is heavily based on the bind named.conf format: it's quite > easy to parse and very flexible.) . We start by defining the databases > to use. Each database has a driver to use and a root from which we start > looking. Would it be possible to "mount" multiple databases at the same root? This would let you use a remote db to pull in initial values, and write changes out to a local db (both "mounted" at /). -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
