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

[Steve Murphy]

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

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?

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

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


=========== ANOTHER ISSUE
======================================================

2. There is NO NAME FOR THE FORMAT IN extensions.conf!!!!! This is very
irritating to me!!! You can't say it's config file format; it's
definitely more than that. You can't say it's "dialplan", because it's
not the exclusive realm of the dialplan, either. Both extensions.conf,
and extensions.ael can form the "dialplan". AEL dialplans are written in
the AEL language, in the AEL format, however you want to say it. But
extensions.conf is.... in extensions.conf format? The extensions.conf
language? That's a five-syllable 'word'....

Ugh!!!!!!!!!!!!!!!!!!

So, if y'all don't mind, I'd like to name the darn format something easy
to say, and elevate extensions.conf to a language... with a NAME! But
what would be a good name for this language?  

EDC   (Extensions.Dot.Conf)
CFD   (Config File Dialplan)
ADPL  (Asterisk Dialplan Prog. Lang.)
ANDF  (Asterisk Native Dialplan Format)
ASDF  (Asterisk Simple Dialplan Format) (a roll of your typing fingers 
       across the keybd)
DUNG  (Dialplan Understandable Native lanGuage)
SPLAT (Simple Programming Language for Asterisk conTrol) (like a bug on
your
       windshield: * )

I realize it's kinda late in the game! Books have been published, docs
are written, and none of it mentions the name of the format, only the
file. But history is malleable! We can start using a new name now, and
kinda slide it into literature as time goes by... in the xth edition of
books, etc.

murf


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20071025/ff72c4dc/attachment.bin