[asterisk-users] Any reason to *not* use AEL? (Also, MixMonitor q)

[Steve Murphy]

On Tue, 2008-06-03 at 09:33 -0500, Sherwood McGowan wrote:
> Mindaugas Kezys wrote:
> >
> > Does Asterisk Realtime support AEL?
> >
> >  
> >
> > Regards,
> >
> > Mindaugas Kezys
> >
> > http://www.kolmisoft.com
> >
> >  
> >
> > *From:* asterisk-users-bounces at lists.digium.com 
> > [mailto:asterisk-users-bounces at lists.digium.com] *On Behalf Of 
> > *Gonzalo Servat
> > *Sent:* Tuesday, June 03, 2008 5:07 PM
> > *To:* Asterisk Users Mailing List - Non-Commercial Discussion
> > *Subject:* Re: [asterisk-users] Any reason to *not* use AEL? (Also, 
> > MixMonitor q)
> >
> >  
> >
> > On Tue, Jun 3, 2008 at 10:41 AM, Eric Wieling <eric at fnords.org 
> > <mailto:eric at fnords.org>> wrote:
> >
> >     AEL in 1.4 was the first version of AEL that most people consider
> >     "stable".  Since not many people uses AEL, you won't get nearly as
> >     much
> >     (if any) community support compared to if you are using the
> >     non-AEL syntax.
> >
> >
> > Really? Why would anyone want to write a dialplan using the old 
> > extensions.conf syntax? That sort of syntax personally drove me nuts 
> > (and real messy). I've got my entire dialplan on AEL (using Asterisk 
> > 1.6.0).
> >
> >
> > - 

> Not sure what you mean, but if you mean realtime dialplan, then no, you 
> can't use AEL for that. However, we might wish to see if Murf knows if 
> this can be done.
> 

extensions.conf is like assembler; it's a very strict, line per
instruction
format, 4 fields per line, that is able to be read in by normal config
file
parsers. It is in turn compiled into the internal asterisk data
structures.

AEL is more free form. Storing the dial plan in AEL format in a db
would 
be pretty useless. However, the extensions.conf isn't so bad in a db, as
it still has the 4 columns, row per instruction sort of format.

But in general, I have to ask, as a programmer, if it's really, really
a good idea to store code in a db. The dialplan is a mixture of both
dialplan code and data, in the form of extensions.

But storing dialplan "code", as in a sequence of application calls,
is a slow way to execute your dialplan code.

And storing patterned extensions (extensions starting with _, like
_10XXXXXXXXX or whatever), is a really slow way to match pattern
extensions. My advise to everyone is this: Realtime is great, but
don't store extension patterns in there, and don't store your dialplan
code in there, if you can help it. It'd be much better to use your db
to store 'exact' extension data. Trying to find the best pattern match
via realtime is excruciatingly slow, as it calls up every extension in
the db for
that context, and then decides on the best match.  DB's do a great
job at storing large numbers of uniquely keyed data that you can find
via
exact matches. So, use a general exten patten in your dialplan, and
then do a DB() lookup from there.

If you find a bug in your dialplan code, you've got to change it in two
places, in the realtime db, and you'd best have it in your original
source as well, in case you need to reload/recover your db or whatever.
A DB is a lousy source-code control system. Use cvs or subversion or git
or something to store your dialplan code instead. That way, you can back
out change sets, etc, and track your changes in a much more practical
way.

Just my two cents.

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-users/attachments/20080603/409f27fe/attachment.bin