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

[Sherwood McGowan]

Steve Murphy wrote:
> 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
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
I personally agree completely, I HATE using RealTime extensions when I 
don't have a need for the ability to modify the dialplan without 
reloading (almost NEVER needed)

-- 
Sherwood McGowan
VoIP / Telecom Solutions
sherwood.mcgowan at gmail.com