I believe that for this project to succeed a well defined configuration API/Library needs to be created for as many languages as possible. For a start we would target:
bash and other shells
and any other languages we can think of. Then one by one in cooperation with each project bring them over to the config libraries. I admit that this may be asking a lot from some projects to cooperate but I believe most will. Maybe a translation API for to cater for the odd project that does not wish to use the new API.
It may be necessary to have dual formatted conf files in the interim. One that the legacy program reads and one that uses the API with a config parser to write it out as the legacy config file. This is not desirable but until the config library is ported to that particular program it wiull suffice as an interim measure.
Today when writing a program it is required to write an entire parser to read and verify config files. With the library already built it then becomes a few simple calls to it. Required paramers, dependancies, options etc,etc are all handled easily and consistantly with the new libraries.
The exact format of the configuration files is yet to be decided. Some cry XML here and others RDP there. This must be decided first on the merits and carry on from there. Personally it does not matter to me what is used, but that it is agreed upon soon. I would hope that once a discussion specifically for deciding the file format is completed that we can all move to the next stage. (It really does not matter what we use as long as it will do the job). Anyone follow the unixconfig mailing list. That is where it died. Come on if we can agree on this quicker we can progress quicker.
Once the file format is decided a clear and precise definition for types, dependancies, requirements, etc. needs to be formally documented and agreed upon.
OK, now write the Libraries for each of the languages that wish to be supported. The API should be the same for each language (as it can be). Write reference code and examples for each language with good documentation (Now there's another ....), and testing etc.
We then can target certain projects and cooperate in the rewrite of the configuration sections of code to use the standard libraries that we have provided.
Then dependacies between programs, global variables such as (HOSTNAME) can be accessed by all programs. etc, etc.
This can extend to enterprise management systems.
The GUI bit should then be the easy part. But it is important that the GUI parts are developed along the way in several reference languages so that on release date we have a product.
It would be great to have the configuration system define the GUI components and layout without having to write the code to do it. The easier this is the better. The configuration can define the checkboxes, textfields, comboboxes, tables, help, dependancies, requires, ordering tabs, wizards, etc, etc. There should be little need on the GUI end to write a great deal of code. We should also include a cursor driven configuration system or even a purely text based configurator. It is all in the API for each situation.
This project will need the cooperation and support from many areas of the community. It will require acceptance of decisions that are made on merit. There is definately more than one way to do this. More important is that we use a standard. Maybe in the future some will wonder why we did it this way or that but as long as the standard is adhered to there is no big deal in changing it.
It would be great if members of other projects joined this one and shared there wealth of knowledge. This project is necessary for unix to go ahead.
Lets do it!