[Asterisk-Dev] Current database abstraction effort ?

[Chris Albertson]

One thing to remember is that Asterisk _already_ uses a database
(of sorts) to store information read from from extensions.conf
and the other .conf files.  Also note that the .conf parser is a
loadable module.  It seems to me one way to go would be to
write an optional replacement "parcer" that does ODBC querries
rather then reading from a file.  In other words treat ODBC as
a new "file format"

The trouble is that curretly Asterisk will not re-read files
to check for changes made in real-time.  This could be fixed
without much work by adding the new concept of an "experation
date" tag to every data item stored in Asterisks (current) internal
database.

The experatin date would implement the cache you describe below
in a general purpose way by adding a feature to
Asterisk's current "database" teaching it to re-read data that
has "aged" paste an "experation time".

By loading the .conf
parcer and setting the experation times to zero (zero==don't expire)
the current method is presevered.  By setting the experation
times to time()+n
and keeping the .conf file parser you force a re-load (from
extensions.conf) every n seconds.

By loading the new ODBC "parser" you will get the extnsion
data from a cached eternal data source which could be a DBMS,
LDAP or an ASCII CSV file.

In less words:

1) Asterisk already has a cache - it's internal database.  What's
lacking is ability to refresh that cache based on timeout

2) Asterisk alread has the abilty to read config data from various
different source but only the .conf source is implemented at this
time.  You need to implement another source

--- Nicolas Bougues <nbougues-listes at axialys.net> wrote:
> On Tue, Jan 06, 2004 at 03:47:48AM -0600, Steven Critchfield wrote:
> > 
> > BTW, extension lookups in a DB more than once is wasteful and way
> > suboptimal. Loading them all at start time makes the DB nothing
> more
> > than a fancy flat file with a funny editing language.
> > 
> 
> I agree with that. It has one advantage though : it's centralised. It
> matters when you have several servers to manage.
> 
> Furthermore, I'm still planning how to do things, but it will
> probably
> be either :
> - entire contexts lookups, with caching. The first lookup would be
>   done when required, and a new one when the context is needed again
>   and the cache has expired
> - a specific lookup application : I'm mostly interested in these
>   dynamic lookups for :
>   - outgoing calls routing
>   - local AGI (or AGI-alike) scripts launching
>   So this could be handled inside a specific extension app (somewhat
>   like what Enum does).
> 
> > Also, have you given any thought as to how you can maintain
> comments in
> > the configuration that are relevant when the DB doesn't insure
> order of
> > results? 
> 
> Keeping order in a database is fairly easy, just add a field for
> that. About comments, well, I must admit I don't really care, for the
> reasons I explained earlier.
> 
> The goal is not necessarily to provide a full replacement for
> extensions.conf, but rather to enable some database-lookup for
> various
> routing decisions.
> 
> The same goes for extensions configuration from inside Asterisk : it
> does make sense to alter them using CLI at runtime when they're
> "statically" in a file. But much less when they're dynamically looked
> up in a DB.
> 
> -- 
> Nicolas Bougues
> Axialys Interactive
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev


=====
Chris Albertson
  Home:   310-376-1029  chrisalbertson90278 at yahoo.com
  Cell:   310-990-7550
  Office: 310-336-5189  Christopher.J.Albertson at aero.org
  KG6OMK

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus