For configuration: 1) Should follow the RDF XML standard, including RDF Schema, so that you can perform validation on configuration files. I've often had the problem where my configuration file is missing something that got lost in the shuffle between development, test and production code. Having a schema that the configuration file must validate against would help with this problem.
An example of this would be if I added a field to the configuration file for a project, such as DEFAULT_DIRECTORY which is the path on the server where xhtml files will be built, there should be a way to validate that the field exists when it is loaded. Also you should be able to restrict fields and values. I don't know how many times one of my junior programmers throws something into the config file that either does not belong, or is already there. Another reason to follow the RDF spec is how the values of a key/value pair can be a URI to another config file. This would allow you to break down your configuration files into smaller pieces and use a 'meta' config file to combine them, among other things. 2) Should make it easy to make global changes as you move configuration files from development to test and production. This is something I deal with all the time. I'll have a config file with values for directories and host names that work for development, but need to be altered for our test and production enviroments. The best example is host names for our DBI database connections. Right now I'll have two config files per project, one with values that stick, like the constants for directories that need to be created on a website, and a seperate files for values that change, like the host name. The process of moving these around can be error prone. There should be a way of automating this. I was thinking that the configuration service should know what are sticky values, and what should change, and when you export updates to test and production, it automatically validates the changes, makes sure you have everything you need, and doesn't overight server specific information. Stephen Adkins wrote: > Hi, > > I recently requested comments on a P5EE Security API. > While considering this myself (and reexamining some of the > component lists that have been created), I realize that > we need a Configuration API simultaneous with the > Security API. However we are going to configure the > Security system would presumably be the same way that > we would configure all of our components. > > The J2EE uses an XML deployment descriptor for all of their > configuration needs. > > This is a request for comments on Configuration. > > My thoughts are as follows. > * One configuration file should be able to satisfy all P5EE components > * When read in, the configuration data should be represented > by a reference to a hash containing a multi-level data structure > * The config API should have a pluggable interface so that a > "driver" can be written to get the configuration information > from anywhere > * The default driver should read a config file which contains > Perl which can be "eval-ed" for speed (i.e. such as would > be spit out by Data::Dumper) > * An alternate driver should be available which reads an XML > config file and converts it to the desired format. > (Optionally, this converted/native form of the data might > be cached as Data::Dumper-ed output or as a Storable on disk. > This would improve performance, the way XML::Simple does.) > > I have a few more foundational questions which I will send in > other emails to keep the discussion threads clean in the archives. > > Stephen > http://www.officevision.com/pub/p5ee > > P.S. I have added links to Paul Kulchenko's Component List and > Greg McCarroll's Component Mini-Specs here. > > http://www.officevision.com/pub/p5ee/p5ee_modules.html
