[Asterisk-Dev] Flexible configuration/ Data abstraction

[Steven Critchfield]

On Thu, 2004-04-08 at 15:03, Steven Sokol wrote:
> 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.

My suggestion here would be to make all config lookups do something
similar to a domain, key and any subkeying lookups for config options.
This would allow for fairly easy mapping to a database for those who so
badly want a database under everything. IT would allow a mapping to some
form of XPATH for those who want to have XML under everything. I think
it would still work well for the flat files. The point being here that
you get to a common parameter lookup form, and the layer below can
decide if it is a in memory lookup or a remote lookup. For flat files,
you could do a stat on the appropriate file to see if it is updated, and
if so reload it, else work with your local cached memory copy. Databases
could just do the lookup all the time.

This approach is probably the only way I would get behind such a change
as it would enable those of us who want to, to keep our installs really
simple and free of add on libraries. 


> 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.

This goes back to the idea of a central SQL resource idea. This would be
great and would help share database resources. Tie to it the idea that
once it is centralized and made a generic resource, you could do things
such as quickly build a wrapper piece between the above mentioned config
changes to the SQL code to implement it for any database supported at
the lower level. In fact, if you could write the current config parser
into the SQL resource file, you could then probably implement all config
storage files via this one driver to make things even easier to deal
with.  
-- 
Steven Critchfield  <critch at basesys.com>