[kepler-dev] [Bug 4394] - Need to develop requirements for configuration subsystem

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4394


berkley at nceas.ucsb.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #8 from berkley at nceas.ucsb.edu  2009-10-05 11:53 -------
After having a conference call about the requirements for the config system
last friday, I think we are in agreement on requirements.  We now need to have
a discussion about design details.  The first discussion should be on alternate
representation formats for serialized config files. 

Below are the agreed upon requirements.  They are also listed at 
https://kepler-project.org/developers/teams/framework/kepler-configuration/proposed-future-kepler-configuration-system

1) A module is able to add configuration properties to the configuration

2) A module is able to read its own configuration properties

3) A module is able to add or override configuration properties added by other
modules.

4) A module is able to overwrite another module's configuration properties

5) A module can indicate whether a property is mutable (i.e., if property
changes are noticed and incorporated without restarting the application).  At
runtime, only mutable properties can be overwritten.  It is the responsibility
of all modules to utilize mutable properties to monitor those properties and
respond appropriately to changes.

6) A configuration property can have either or both of a single scalar value or
a list of subordinate configuration properties.  Subordinate configuration
properties must have unique names within their parent property.

7) The configuration system is able to notify modules or other registered
listeners that a configuration change has taken place

8) The configuration system is able to serialize each module's configuration
properties as text

9) The configuration serialization should be able to store different language
versions of each property file (internationalizable)

10)  Each module can have its own configuration and can organize its
configuration into any number of namespaces, allowing the module to organize
its properties into groups.  One use case for this is to allow a module to
separate its UI strings from other configuration properties.

11) The configuration system is able to tell which module owns a configuration
property

12) The configuration system is able to store default configuration properties
separately from user-modified configuration properties. Consider whether user
preference files, including loading and sharing of such files, is in scope or
not.

13) The configuration system should be loaded under all variants of the Kepler
application and should have minimal dependencies.

14) The configuration system should be able to store and make accessible
documentation about configuration properties (name, description(s), etc.)

15) The configuration system stores strings only.  It is up to a module to cast
strings to implied value types.
    -- desire to include data types as as part of the model (rather than only
accept strings)
    -- desire to have utility methods for doing casting (e.g., getValueAsInt)
    -- change this requirement to:  The configuration system will support basic
types.  If no type is specified, the type will default to String.
    -- basic types TBD.

16) The config system should define the set of allowable characters for use in
names (e.g., no spaces, or should be java identifiers)

17) The configuration system should specifically consider if and how
configuration values or sets of values from the command-line, environment
variables, module.txt and other sources should be merged or provided with
values from configuration files