Re^2: RFC: Application Configuration Management

[ides]

All of the points so far are very valid. But I guess I didn't make myself very clear. I'm not looking to support a position that you should use different config syntaxes just willy nilly.

What I'm am essentially building is a config file interface, much like DBI that would all you to divorce how a particular application is configured from the actual code. This isn't for any one particular application, but a library for use in building applications. A config file abstraction layer if you will.

Code cares about very few things when it comes to configuration information. Most in fact are simple scalars of information. Database name, password, number of items to show on a page, etc. Some are lists such as allowed IP ranges. But very little else. Looking at all of the various config file parsers on CPAN show that they all basically provide the same types of operations, just with a different syntax for each ( well most, some have exactly the same syntax, just a different API ).

By admin, I mean whoever is installing, configuring, and/or maintaining the system once it is in production. This could be the same person who wrote it, a different person in the same department, or someone in another country who just happens to be using your software.

I would hope that people would stay consistent within their own realms ( their home, their department, their company, etc. ). But I see this as actually helping with that. Say my shop likes to configure everything in a SQL database. We've written a neat config management tool to make and track changes, etc. Along comes some application we need to fold into our mix, but it uses a INI style flat file configuration. Is having this one app use a different style the end of the world? No. Is it a pain? Sure. Is it a reason to not use the application? Could be, depends on the exact scenario. Wouldn't it be nice if I could use basically whatever configuration method *I* choose and have the application not care?

One situation I run into quite often is that you have a web application written in say mod_perl and you are using PerlSetVars to pass in configuration information. Being a web application written in mod_perl this seems perfectly resonable and expected. Later in life you realize you are going to need to run a couple of cron jobs to do some batch processing in your app that you had not originally forseen. It would be really nice if the cron jobs could simply share the same configuration information as the web portion, but that would non-trivial. So you end up either rewriting the web app's config code to use a flat file format they can both share or duplicate your config via commandline arguments to the cron jobs. In a situation where you have only a few applications to maintain this isn't hard to remember what is where and why. But now expand that situation to where you maintain 75+ different applications written by several different people over the course of the last 7 years. Now it's pretty darn easy to change say a database password or other piece of configuration information in your Apache config, but neglect to make the change in your crontab. That one cron not running could be difference between having a job and not having one. ;)

Here is another example that I hope helps illustrate my point. Suppose you have an application that originally was only supposed to support one instance. Not that there are any real limitations in the application, just that it was never dreamed that you'd want to run multiple of them. So following with that the programmer used a simple configuration system you don't like. For the purposes of this example, let's say we don't like XML config files, or Apache config files, or GUI config apps with a binary registry, whatever... it doesn't matter. For whatever reason you either simply don't like the config system, there are problems with it when using multiple instances of the application, or it simply does not fit in with the overall scheme you are using in a particular realm.

Now suppose you need to run hundreds of them. Maybe in a web hosting scenario. You've got this really great customer management application that handles nearly everything for you in a database, but now you have to write special code to build these text config files, publish them onto the server, etc, etc, etc. If the application had been written to where it was "config system agnostic" you would simply need to change the instance entry in that one file and presto your preferred way of configuration is available.

The goal is to support as many different configuration "systems" as possible. It probably will not be possible to support every feature of every variant of everything out there. But ya' gotta start somewhere. :)

[dragonchild]

The reason DBI works is that it doesn't do anything. It provides a API, and a very simple one, at that. Plus, it's working on top of an extremely well-defined (if poorly thought-out) language - SQL. If you don't believe me, think about what it would take to build a DBD for DBM::Deep.

It seems to me that you are getting ahead of yourself. What you really want is a way of standard way of querying configuration, regardless of how it's stored. Define that and you can use DBI as your configuration manager with people providing DBD's for each configuration method.

Good luck.