[Asterisk-Dev] Flexible configuration/ Data abstraction

[Steven Sokol]

John Todd provided his quarterly list of good ideas today.  (I think each of
his ideas probably warrants its own flurry of emails.)  I would like to take
a moment to beat my own dead horse...

One of the key changes I would like to see introduced into Asterisk is one
or more very thin abstraction layers that allow configuration data (like
that which is currently stored in the .conf files) to be read from different
sources without having to make wholesale changes to the various channel,
application, resource, and pbx sources.

I propose that we brainstorm a thin, highly efficient common layer that can
in-turn load a module or modules that do the actual reading and writing.
Asterisk would include a default module that would use the configuration
files as they stand today.  Those of use who want/need a different storage
mechanism would have a clean method of directing Asterisk to look elsewhere
for the data.

After an admittedly cursory review of the code I see several places that
require change:

The first is config.c, which provides most of the functionality to read the
.conf files and which is referenced in nearly every other component of
Asterisk.  The easiest (thought it may be a bit of a hack) way of getting
started would seem to be replacing this code.  Config.c would be re-coded to
read a config file of its own (the "Master" config -- config.conf?) then
load and register the proper configuration module.

The second effort would appear to be in pbc.c and in pbx/pbx_config.c.  We
could either continue to load the entire dialplan into memory at
startup/reload and simply alter the load_module code to read from the
abstract data layer, or we could go even further and replace the search
routines in pbx_find_extension with calls the abstraction layer.

Other changes could include the CDR handler (we could actually go to a
single CDR interface instead of having PGSQL, MySQL, etc floating around the
periphery), the logger (logging to a central DB makes sense in some cases),
and several of the applications.

I currently have my own Asterisk systems hacked to use PGSQL for SIP, IAX2,
and Extensions/Contexts.  I have this working just fine, but every time I
want to update to the latest CVS, I have to worry if my patches will apply
properly.  I suspect I am not the only one facing this issue.  By decoupling
the data interface code from the core code we could avoid these issues
altogether.

Thoughts?

Steven Sokol
Owner/Manager
Sokol & Associates, LLC

Phone:  816.822.1807
IaxTel: 700.613.9004
Web:    http://www.sokol-associates.com