[kepler-dev] [Bug 3948] - Create new configuration system supporting modules

[bugzilla-daemon at ecoinformatics.org]

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





------- Comment #8 from berkley at nceas.ucsb.edu  2009-10-19 13:56 -------
I've been working on prototyping and setting up unit tests for the
configuration system.  There are a few issues I've been running into.  I'd like
to get a general discussion of these issues and try to come to some
conclusions.  

The issue we left off with on the last call is what serialization format to
use.  The conclusion I've come to is that we really do not *need* to come up
with one standard configuration format to use.  If we think this is very
important, we should, but the system I've been working on uses interfaces for
serialization and deserialization making it very easy to plug different readers
and writers in.  

I've been experimenting with YAML and Apache Commons Configuration.  Commons is
much more flexible.  It can read/write 9 different types of files. It supports
highly nested structures very well.  XML is the easiest format to use with
Commons.

While the formatting of the YAML configuration file is very nice in its
simplicity, nested structures are somewhat difficult to handle in the API. 
Since most of our current configuration is highly nested, it's my opinion that
commons should be used for porting these configuration files to the new system.
 YAML could be used for new, or more simply structured files.  The use of soft
tabs to indicate nesting is somewhat fragile, imho, since accidentally deleting
a couple spaces can give you a vastly different structure that what you
intended.

Another issue is when a serialization should take place.  There are a couple
different choices.  1) Serialize the configuration file whenever a change is
made.  This is the Mac OSX style of doing things.  2) Wait for a calling class
to initialize a serialization (basically calling save()).  Number 1 makes it
easier to keep a serialized config file in sync with the more abstract
ConfigurationProperty class.  Number 2 is simpler and will allow many
properties to change then allow the entire file to be overwritten which is a
simpler operation that doing a diff to just update the "dirty" properties.

One more issue that I've come up with is that requirement #6 should be changed.
 It states that all subproperties should have a unique name.  This should not
be a requirement since we have many instances of subproperties in our current
config files that use the same name multiple times.  This is not a requirement
of XML or any other nested language that I know of.  Anyone object to me
changing this requirement?

I'll leave this open to discussion here on bugzilla and on kepler-dev.  If we
think we need a phone call to figure out these issues (or if anyone has any
other issues) let me know and we can arrange that.