On Tue, 19 May 1998, Oliver Elphick wrote: > Well, having looked at COAS, it seems not to dictate any particular data > format; it has to cope with a large number of independently developed > packages, each with its own format. To add a new one means writing a > module which plugs into COAS to handle the new package. Once COAS is > available, this can easily be done.
Specificaly the information I was talking about is the schema sub directory. It is not quite what I was expecting (last I looked at coas it was not for this detail) and I'm really not terribly enthused about it. What I was thinking (and what some of the COAS docs claimed) was that it was much like the SNMP MIB descriptions. Let me elaborate.. For each possible question we would describe the form that the answer can take and we would describe what we are asking. SNMP uses ASN.1 notation and looks something like sysORIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The auxiliary variable used for identifying instances of the columnar objects in the sysORTable." ::= { sysOREntry 1 } COAS provides the SYNTAX information but completely ingores the description - your format completely ingores syntax. What we need is description, syntax, defaults and so on as we scale up to more interactive systems Maybe like mailname OBJECT-TYPE SYNTAX STRING STATUS mandatory DEFAULT "debian.org" DESCRIPTION "The externaly visable mail name of the system" ::= { .. } I don't know if we want to use ASN.1 - It seems like a nice idea to use existing defined things however. We could probably even use the same form as the Package files, or we could use SGML, or something totally new - it really doesn't matter, any thing I say about ASN.1 can be applied just as well if it is in some other form. Like the way SNMP works the ASN.1 description would serve only as the information that the UI tools use to understand what they are viewing. The actual answers to the questions could be stored in some arbitary database - this is something the packager does not have to deal with. As we get more fancy we can extend the description to encompass a wider range of database options [say native config files for the package] and to encompass actual management. So, to the package writer the tasks required of them would be to write a Description of the configuration questions and then in their script instead of prompting they would call a query program which would prompt depending on various conditions. Now, how this solves Ian's points, #1 - I read this as meaning the questions are seperable - they would be present in the Description file (MIB in SNMP notation) We could make them avail for download via http just like changelogs are now. #2 - The package has control here, it's script is performing the queries into the database. As we scale up to pre-configuration the package can optionally provide a UI Plugin that provides it's logic functions If it does not then the user will simply have more things to answer than is stricly relevent to their choices. #3 - If we follow the SNMP model then each quesiton has BOTH a name and a numeric string arranged in a heigharchy (debian.mail.mailname for instance) #4 - This is just a field in the 'MIB' #5 - It is, because each question has a structured form we can have a generic GUI that can browse the question tree. With options to install 'Plugins' in the GUI we can scale even more so. #6 - Implementation detail #7 - ?? #8 - Implementation detail (related to #4) #9 - This is handled more generally by typing the responses in ASN.1 - this is MUCH more suited to a generic GUI than a regexp, but it does not exclude the possibility of a regexp type. #10 - This is not covered in the SNMP model. I suggest a a substition system in the description feild that allows lookup and substition of other database entries and to a lesser extent environment variables (env vars limit the usefullness of a GUI tool) Perhaps $(debian.mail.mailname) and #($FOO) ? There are also a few other interesting benifits #0 - We are -VERY- similar to something estabilished, we don't create new languages or even so much new concepts #1 - SNMP presents itself as good choice for a remote administration protocol #2 - We provide a native configuation storage system for apps/scripts that desire. This is instead of the usual technique we have been using of having a script as a conffile or having the script source another file. #3 - Using a heigharchical structure gives each package alot of freedom in what variables they can have #4 - The package writer does not have to use the query program to generate the prompts, they can come from within the script, an external program, a GUI plugin, etc - there is alot of flexability in how the information can be inserted into the database and how it can be taken out of the database - this is nescessary as we move to a more plugin rich environment (imagine how ecompassing a sendmail plugin could be) Some things we should look at, - Free ASN.1 parsers/libraries, I think one is around - What fields can be borrowed from SNMP and what more do we need? - Consider how we would model some of the existing setup scripts in ASN.1 and verifiy that this -IS- an acceptable model. [Anyone want to do these? I should be working on APT.] dtxtdb is not at all the same solution as this - it models the backend native database/cache, which does not deal with any of these issues. As a final thought, it is my belief that implementing a 'simple' system like Oliver started with would be suicide. We would lock ourselves into something that is not extensible or realizable into a powerfull GUI. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]