Configuration 4 GNU (CFG)
|
|
System Requirements | | |
|---|
Requirements are precise and detailed descriptions of various
functions and attributes of the proposed system.
Functional requirements are descriptions of specific features or
functions of the system. They are things the user can do with
the software. They can usually be modeled as having inputs,
processing, and outputs.
Create a new configuration node| Revision History |
|---|
| Revision 1.0 | 10 Oct 2002 | jal | | Added to SRS |
Describes how a user will create a new configuration "node."
Parent node. The user shall specify the node
in which the new node will be created. For example, in a GUI
application, the user may select the node by clicking on it
once with the mouse. For a command-line utility, it may
be specified as an argument. Node class. The user shall specify the class
of which the new node is a member. In a GUI application,
the class may be selected as a submenu of the
menu or it may be selected from a dialog box. Initial data. Many nodes will require initial
data to be created, such as the install location of the
configuration file for which it edits, or the name of the
object which it is creating. In a GUI application, a form will
be presented to the user where the user will enter the necessary
information before the object is created.
A configuration class shall define certain actions that need
to be performed in order to create a new node of that class.
These actions shall be performed using the information provided.
The node, once created, will need to be added to the list of the
parent node's children.
The output of the creation of the new node will depend on
the class, but it will almost certainly require the creation
of a new configuration file or addition of data to an existing
file. In addition, the data for the parent node will need to
be modified.
The user shall be given the full identifier of the new
configuration node.
Mandatory. Required for version 1.0. Read a configuration setting
Although Config4GNU does not provide a framework for
applications to read their configuration settings, users
who want to make changes to the configuration will need
to read the existing values to intelligently set new
values.
Configuration data is considered a type of data that does
not change very often, meaning aggressive caching of values
will be allowed when the system becomes distributed.
Reading configuration data shall be subject to access control
information.
To access a configuration value, the input is a
configuration property identifier (i.e. a "path").
No processing is required for this function. The function outputs the value of the specified
configuration property. Mandatory. Required for version 1.0. Read a nonexistent configuration setting
If the user needs the value of a property that is not actually
defined in the configuration file, a "phantom" property should
be created, given the default value for the property, and given
to the user. This allows forms to contain controls bound to
properties that are not necessarily defined in the native
configuration file.
Consider this share definition from Samba as an example:
| Example 1. A share definition | [myfiles]
path = /var/myfiles
writeable = yes |
Now consider a form that displays a checkbox for whether or
not the share is "browseable." This checkbox should be bound
to the property browseable. In order for
the checkbox to bind to an actual object, and without requiring
the configuration file to contain the implicit
"browseable = yes" statement, a phantom property is created
and used as the bound target of the checkbox.
See also
Changing the content of a Phantom Object.
Changing the content of a Phantom Object
When a phantom object's content is changed from its original
default value, it should be saved in the native configuration
file the next time the native configuration file is updated.
Therefore, as soon as the phantom object is modified, it
becomes real.
Notification of added property
When a property is added to an object, notification should be
sent to any listeners on that object to the
property_added event.
Open two windows containing the same configuration tree.
Select an object and make sure that object is visible in
both windows. Use one window to add a property. The added
property should appear in the other window as well as the
first window.
Setting a configuration setting
One of the obvious requirements is for users to be able
write values to the configuration files. Setting configuration
values not only includes modifying existing values, but
adding and removing properties.
Setting configuration data shall be subject to access control
information.
To write a configuration value, the input is a
configuration property identifier (i.e. a "path")
and the value to write to that property.
Depending on the application, special actions may need to
be performed to "activate" the configuration. For instance,
restarting the application will force the program to
reread its configuration file.
There is no output for this function.
Mandatory. Required for version 1.0. List all of the properties of a configuration node
Users shall be able to list all of the properties
of a configuration node. This way users can see what
properties are available for change.
User may list all set properties, as well as unset properties.
Unset properties are properties that are defined in the
schema file(s) but not actually present in the configuration
file. (Most applications do not require every single parameter
to be present in a configuration file and define default
behavior for parameters that are not present.)
To list properties of a configuration node, the input is a
configuration node identifier.
No special processing required.
The output is a list of configuration property identifiers
that are properties of the specified configuration node.
Mandatory. Required for version 1.0. List all of the child nodes of a configuration node| Revision History |
|---|
| Revision 1.0 | 12 Oct 2002 | jal | | Added to SRS |
Since configuration nodes exist within other nodes,
users will need to list all of the child nodes of a configuration
node.
The user shall provide an identifier of the configuration
node whose children should be listed.
No special processing required.
Config4GNU shall provide the user a list of configuration
node identifiers which are children of the specified
node.
Mandatory. Required for version 1.0. Delete a configuration node| Revision History |
|---|
| Revision 1.0 | 12 Oct 2002 | jal | | Added to SRS |
From time to time, a user shall have to delete a configuration
node.
This action shall be subject to access control lists.
The user shall provide Config4GNU with the configuration node
identifier of the node that shall be deleted.
The configuration class to which the node belongs shall define
the actions needed to delete nodes of that class. These
actions shall be performed.
Deleting a node will require modification or deletion of
the underlying configuration files.
Deleting a node will require removing it from the parent's
list of children.
The user who requested the deletion shall be notified that
the node has been deleted.
Mandatory. Required for version 1.0. Non-functional Requirements
Non-functional requirements describe characteristics and attributes
of the system. They may also describe constraints that must be
placed on the system. Examples are performance, efficiency, and
security requirements.
Immutability of Configuration Files
When Config4GNU makes modifications to configuration files
the original configuration files shall only be modified in the
most minimal manner required for the change to take affect.
All non-configuration data shall be preserved, including:
comments whitespace order of parameters
A way to test this requirement is to have a bunch of
various configuration files, pipe the output of the parsing
of each into the unparser and compare that result with the
original, using a utility such as diff. | Example 2. Testing the samba parser/unparser |
$ ./parse.ini.pl smb.conf.original |./unparse.ini.pl >smb.conf.new
$ diff smb.conf.original smb.conf.new
|
Mandatory. Required functionality for version 1.0. External Interface Requirements
External interface requirements describe the interfaces required
to interact with other software and with users. Possible requirements
in this area would be the ability to restart an application when
its configuration changes and external programs to do user
authentication.
Activation of configuration
The configuration definition files shall provide the information
necessary for "activating" a configuration--that is, performing
whatever actions are necessary to get the application to reread
its configuration.
External programs to read/set configuration values
Certain configuration properties may need an external program
to set the value. For example, to set a user's password you
may want to invoke the passwd program with
the necessary arguments rather than directly edit the
passwd file.
There shall be a command-line user interface which will allow
the basic functionality of Config4GNU to be executed from both
interactive and noninteractive shells. This command-line
interface will have to allow access to all essential functions
described in
.
Mandatory. Required for version 1.0.
There shall be a web interface which will allow the basic
functionality of Config4GNU to be accessed from other computers
via a web browser.
There shall be a graphical user interface which will allow
the functionality of Config4GNU to be accessed from a graphical
desktop.
The graphical user interface shall use the Gtk+ toolkit.
There shall be an LDAP interface which will allow the
functionality of Config4GNU to be accessed from a common
LDAP browser.
To fulfill this requirement, the data model used by Config4GNU
must be compatible to the LDAP specifications.
An example LDAP browser is gq,
available from biot.com/gq/.
Relationships among requirements
| |
|
|
|
|