Configuration 4 GNU (CFG)
|
|
General Description | | |
|---|
In this section the proposed system will be described.
System Goals, Questions, Metrics
For now, this section only contains a broad overview of the major
goals. In the future, this section should contain precise
procedures for verifying that the goals are being met.
Provide multiple interfaces (command line,
web-based, GUI, LDAP, etc.) that allow users/admins to
modify configuration, with relevant documentation (man pages,
etc.) integrated into the interface. Allow developers to easily create configuration
interfaces for their software which will be automatically
recognized by our system when the software is installed.
Standardize the different types of configuration
files (INI-style, flat/delimited text, Apache-style, etc.)
and provide "parsers" and "unparsers" for all styles.
Include ways for different operating systems and
distributions to tailor the system to their needs. Retain the native human-editable config files in
/etc as the authoritative copy of system configuration and
avoid mangling comments and indentation.
A Node in Config4GNU is
an aspect of configuration. It is composed of child nodes
and properties. If compared to the Windows registry, it is
a "key". If compared to a Unix filesystem, it is a
"directory."
Nodes belong to a node class, and they have a name that is
unique among all the nodes that are contained within the
same parent.
A Node Class in Config4GNU defines common
properties and methods of a configuration node. For properties,
it defines possible property names, their default values, their
data types, and a description of the property. For methods,
they define a name of a method and what actions should be
performed when the user wishes to activate that method.
In addition, the node class defines methods for creating and
deleting a node of the class.
Node classes are subject to inheritence. Node classes can
be specified to "extend" another node class, causing all the
definitions of the extended class to automatically be
present in the sub class.
Node classes shall be identified by a URI (Universal Resource
Identifier) and a name. The URI will work like it does in
XML namespaces. No meaning is attached to the URI; it merely
ensures that third-parties can create their own node classes
without the possibility of a naming conflict.
A Property in Config4GNU
is a single configuration setting. It is attached to a
configuration node, which may contain many properties.
Properties are composed of a name and a value.
A Property Value is an abstract type,
since it can store many different data types. When possible,
a property value will have a way to convert a string to its
data type and back.
A Data Type is a description of the type
of data allowed in a property value. It may also describe
the type of widget used to select the value (e.g. a spinner
control for a numeric value or a drop-down list for a day
of the week).
Many common data types shall be defined by Config4GNU.
Third-party applications who use Config4GNU may provide their
own data types, in the case that the predefined types do
not suffice.
Like node classes, data types will be identified by a URI
and a name, ensuring that naming conflicts will not occur
if used properly.
User types and characteristics
The most common user of Config4GNU is the system administrator
who wants to make changes to the configuration of an
application on the system. This system administrator does not
want to edit text files, is not completely familiar with the
syntax of the configuration file for the particular
application, or wants to somehow automate a configuration
file change.
Developers of applications,
as defined in this paper, will be interested in Config4GNU
supporting their applications. To do this they will need to
know how to define the appropriate plugins to let users of
Config4GNU use Config4GNU to configure their applications.
Config4GNU will also be designed so that Desktop Linux Users
will be able to easily configure their desktop computer.
A difference between the Desktop Linux User and a System
Administrator is that Desktop Linux Users will need to
change system properties often and not be concerned very
much about daemons, and the System Administrator will be
more interested in working with daemons and other applications
on the system.
Constraints and assumptions
Risks are those things that could prevent Config4GNU from being
a successful project. It is good to think about what risks there
are so developers can concentrate on addressing these issues
first. As development continues, new risks will be discovered,
and existing risks will become obsolete. This section should
be updated accordingly.
A risk is that Config4GNU would be unable to adapt to
different versions of applications. For
instance, what happens when a user upgrades to a version of
Apache that has slightly different configuration options. The
user will want to enter a configuration option for Apache that
Config4GNU doesn't know about. If Config4GNU is unable to
handle this type of situation, it will not be accepted.
Config4GNU will probably not succeed if major application
developers do not decide to support it by bundling updated
configuration definition files with their distributions.
Another risk is that the project's audience are too attached to
editing configuration files manually and see the project as
fixing a problem that does not exist.
A final risk is that there is some system application that we
do not consider that uses a configuration format that is
not representable with the data model that Config4GNU uses.
| |
|
|
|
|