[asterisk-users] extensions.conf vs. AEL

[Steve Murphy]

On Wed, 2007-10-03 at 09:33 -0600, Anthony Francis wrote:
> 
> Eric "ManxPower" Wieling wrote:
> >> Let us not forget that AEL cannot be stored in a database therefore 
> >> rendering you unable to utilize realtime.
> >>     
> >
> > AEL converted into standard extensions.conf syntax in the dialplan.
> >
> >   
> Doesn't this render having used AEL pointless?
> 

Absolutely not! 

Reasons to use AEL:

1. Several semantic checks are done on the AEL that are NOT done if you
go straight to extensions.conf. We try to protect you... from yourself.

2. At least one security issue in USAGE is avoided by having AEL compile
the corresponding code; as to how many more issues will automatically be
handled via
AEL in the future, is impossible to say. We'll see. If you keep coding
via
extensions.conf, be prepared to make corrections... if you do it in AEL,
a restart of Asterisk will hopefully suffice, after AEL is updated.

3. Syntax errors are reported by AEL. It is pretty good at catching all
omissions
and commissions. Better than the extensions.conf parser is. For example,
I don't
know if we catch it now, but if you accidentally say "extem => 3,..."
instead of 
"exten => 3,..." in extensions.conf, that line will silently be dropped.
Sure, we
could fix this, but to fix ALL possible problems will require an
expensive rewrite of the config file parser, from the ground up.

4. You are insulated against any mods to extensions.conf; like the
change to ',' instead of '|' in app arguments. No changes to AEL code
are necessary.

5. In extensions.conf, you have to feed your dialplan to asterisk to
find any problems. AEL provides the standalone parser, aelparse, so you
can correct any problems BEFORE feeding it to a living asterisk.

6. AEL is easier to read, IF you take advantage of the ability to use
tabs, etc. wisely. Especially for nested code. Staying away from goto as
much as possible,
and using the flow of control and looping statements will make your code
easier to read, compose, and maintain in the future. It means fewer bugs
in your code,
and overall this all means lower cost. And higher profits.

7. Repetitious entry of "extenname, priority,"  in your tabular
extensions.conf can lead to subtle errors that could be hard to find,
ESPECIALLY if you resort to using priority NUMBERS instead of "n". And,
if you ARE so foolish as to use just raw numbers, and you have to insert
or delete a line or two, you have to renumber
the remaining lines, and heaven help you if you make a simple error, and
accidentally skip a number.

8. Work flow. Since aelparse allows you to dump the compiled dialplan in
extensions.conf format, you can still use stuff like realtime. You can
use this output against machines that don't even have pbx_ael loaded,
then, and you should be able to use 1.4 compiled dialplans on 1.2
machines, as long as you are careful about what apps you call, and how
you call them.

9. Easier to write code. Good Code. using Goto's in extensions.conf will
allow you to do anything you need to do, but it also results in
spaghetti style code.
While the original author might be able to decrypt it, and  maintain it,
unless it's really well commented, the next guy to play with it, is
going to have a hard time. Following the flow of control thru spaghetti
can get your adrenalin flowing-- and side affects from strange cases and
leakage in the spaghetti can make some devilishly hard to solve
problems.

Think of and treat extensions.conf like assembly code.

Think of and treat AEL like a high(er) level language. For those who
never did the computer science thing, I have just one piece of advise,
and ignore this at your peril: your dialplan is a work of computer
programming. It's software. If you don't treat it that way, and use good
software methodologies, you'll pay your price.

murf



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20071003/9f88c1b5/attachment.bin