Naming Guidelines
For this library to become a success it is necessary that many applications,
utilities and daemons make use of it. To ensure that their naming structure
remains consistent and free from naming clashes I would like
to recommend the following strategy:
- Pick a top-level name for the type of service your program
provides. Names such as mail, ftp or games
sound good. Try to use already existent sections. If not please mail me
the names of the new sections so that I can add them to the kunf
package. Otherwise we will get awkward situations where one has
top-level sections called ham, ham-radio and
amateur-radio which will have to be merged later on (only
an example).
- Pick a second-level name. Use a reasonable subsection (such
as news:nntp or web:browser). This part is optional,
if it is difficult to find a second-level name then leave it out. Again
please mail be additions. Hmm - maybe I should set up an online registration
for names...
- Use the name of your package as third- or second-level name.
Names such as news:nntp:myremotereader or scheduling:mycrond
are good. I think it would be a bad thing to have version numbers in
the names - a new version can always add new entries to the database without
the old version being aware of that data, but if you have separate
sections for different versions the sysadmin will have to fiddle the
configuration on each upgrade and things are liable to get cluttered.
- Use as many subdivisions/subsections within your space as you need,
especially if you think different people will want to configure different
parts of your program. news:nntp:myremotereader:colors,
news:nntp:myremotereader:posting_policy and
news:nntp:myremotereader:diskusage would all make good subsections.
Possible Key Name Reservation
Currently what you call the entries within your sections is entirely
up to you. But maybe at some stage it would be feasible to have a special
section somewhere which could contain a set of standard entries for
each application. I suppose those could be used to stop, start and
restart applications - this would mean that the sysadmin would use
something like an enhanced kunfedit. Once the changes where
made kunfedit would consult those special names and run commands
to synchronize the system with the modifications. But maybe that idea
is for someone else to implement since such a system would only make
use of the kunf library - it would be a sophisticated client
application.
Improvements
For work to be done on the library itself refer to the
TODO file. Help would be greatly appreciated.
You can contact me at
my anti-web-crawler-spam-address.
Related Work
Shortly before I completed this release it occurred to me to search
for work already done on the topic of Linux system configuration.
To my surprise I found an entire
mailing list dedicated to the topic. I was pleased to see that that
group and I had many ideas in common. It seemed that someone on that
group had started work on a library similar to my own, but it seens that that
effort had died off. I hope my work can implement some of their ideas...
I also found a system configuration/management system called
linuxconf
written by Jacques Gelinas. I have not yet had time and space to
investigate it fully, but it seems to be a comprehensive package. I think
there is potential for applications using kunf to make life easier
for linuxconf since linuxconf could use the kunf API
to access the data of the application instead of having to construct
its own parser - but that is just a thought...
Up: index