On Tue, 28 Jul 1998, Joey Hess wrote: > Antti-Juhani Kaijanaho wrote: > > I like everything about it, except the language. IMO it has the wrong > > basic assumption, namely that the configuration module controls the > > frontend like a programmer controls the machine (the language is > > essentially astripped-down special-purpose BASIC). I would like the > > language to be redesigned from scratch, with the assumption that the > > module just _asks_ the frontend, and the frontend is free to either > > 1) echo back the defaults the module has provided, > > 2) return cached data or > > 3) ask the user. > > But this assumption is already made! Notice in the proposal where it talks > about non-interactive frontends, which take care of 1 and 2.
You are missing what he is saying. The current proposal is that we write basically a script to handle the configuration prompting. A script is probably necessary, but I think it probably should be in the post/pre inst not seperate.. Anyhow, the point is that what you have is a package that has a set of variables it needs, you should be able to describe THESE VARIABLES and not THE METHOD TO SET/QUERY the variables, subtle difference. For instance that current proposal does not seem to accomidate a master index of possible configuration values and their meanings and types, all we have a query language. [Envision downloading configuation.gz, firing up your LDAP manipulator and configuring your machine -before installing-] Just to be crystal clear, consider these two different setups. PRINT "Is your clock in GMT?" INPUT foo/gmt boolean true SET foo/configd boolean false STOP And Value: foo/gmt Type: boolean Query: Is your clock in GMT? Default: false Description: This value controls if your CMOS clock is in GMT or UTC If it set to true then no timezone conversion is done on boot and you do not need to worry about daylight savings, but your clock will not be compatible with Windows/dos. If false then you will have to correct your clock after daylight savings changes Value: foo/configd Type: boolean Private: yes Description: Controls some strange internal thing Which is ultimately more usefull? Personally I think the use of the query language as I understood it is not what we -really- want, it serves the purpose of communicating (and controlling!) the query process. What we want is a way to get/set values out of the database, I've been thinking about something like this [excuse my shell] eval `do-query <<END get foo/gmt FOO_GMT set foo/configd yes END` The ideas is that with those parameters do-query would return 'FOO_GMT=true' which would then become a shell variable. A perl module and a C routine could be created to complete the system. The other 'missing' fragment is what to do if the user changes a database entry once the package is installed. It is important to leave that possiblity open so in future we can have 'push' configuration. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
