[asterisk-dev] dialplan sanity and what to call extensions.conf's format?

[Tzafrir Cohen]

On Thu, Oct 25, 2007 at 01:28:13PM -0600, Steve Murphy wrote:
> Uh, a few side issues:
> 
> 1. In all my Astricon preaching on dial plans, I realize I completely
> overlooked a really important dialplan programming tip:
> 
>               In your Dialplan, Do your best to separate Program from
> Data
> 
>                   or, put in a less subtle way:
> 
>               Keep your @$!%!@ data out of your dialplan!!!
> 
> How can you tell you are violating this rule?
>    a. You have extensions.conf (or whatever) in a database, with
> Realtime.
>       Shame on you. Using the dialplan as a database is inefficient and
>       dangerous.
> 
>    b. You have to reload extensions.conf (or whatever) whenever you
> add/sub/mod
>       an extension. If you are modding the logical flow (program), in a
> small
>       situation, then, OK, that'll do. For instance, in my home setup,
> if I have
>       to mod an extension, somehow, the entire balance of the PBX has
> changed,
>       and I need to review the program in its entirety.
>       But, if you are storing all the data about who/what are associated
> with
>       extensions, maybe you need to take a different approach...
> especially
>       when you find yourself making daily/hourly changes to the
>       extensions.conf/ael file....

Actually you only mentioned how one one specifica case mixing code and
data caused a mess. I really don't understand why you suggest that they
should inherently be more separated.

> 
> What IF?
> 
> What if, instead of keeping info about extensions directly in the
> dialplan, you use generic patterns instead, and use a database (astDB,
> oracle, mySQL, pgsql, sqlite, etc),  to store all the particulars so
> that one extension definition's 
> code can take care of everyone?

So instead of spending that time on reload, you spend that time 

> 
> (You could even assign categories of user or whatever in the db, and
> branch
> your logic to handle the different categories.... differently!)
> 
> For instance: you could put all your ex-girlfriend numbers directly in
> the dialplan:
> 
> exten => 100/3075878001, ....voicemail(u100)
> 
> or, you could just simply test a DB and see if the calling party is in
> the blacklist, and route them to voicemail. If you do it this way, the
> advantage is that you can add blacklist numbers and not have to reload
> the dialplan or change any dialplan code. If you use a true db, you can
> make changes from anywhere on the network, and the PBX is not directly
> affected at all.

So you'll need a separate DB lookup for blacklist, a separate dblookup
for calling party, and whatever.

It's setup time vs. call time.

> 
> The idea is to keep the logic and sequence of app calls in the dialplan
> independent of the 'data' of what extension numbers correspond to what
> Zap/, Sip/, IAX/ devices, 

Do they correspond so nicely?

> etc. You should not have to modify your
> extensions.conf/ael but once in a blue moon, ideally! Use patterns to
> funnel the flow of control to generic code that will use a db to fill in
> the blanks you will need to make announcements, bridge calls via Dial(),
> etc.
> 
> Does this make sense? Am I flying in the face of good sense here? Or am
> I insulting people who take pride in their mix of data and program?
> 
> In my opinion, you have two sources of possible errors: errors in
> programming, and errors in the data. Keeping them separate is wise.
> Generating a new version of a program every time a bit in the data
> changes is insane.

But putting the data outside extensions.conf doesn't help that much
here.

-- 
               Tzafrir Cohen       
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir