[asterisk-users] extensions.conf vs. AEL

[Barzilai Spinak]

All this discussion is pointless. As pointless as the discussion of 
assembly versus high-level languages decades ago.
Except most people rooting for "extension.conf" don't even have the 
technical and conceptual amplitude to understand what they are talking 
about... they just want some telephony system to make a quick buck, or 
save in their LD calls...
A lot of Asterisk is technically and architecturally twisted, and 
"spaghettied", and with many redundant ways of doing the same thing (in 
different stages of obsolescence, incompleteness, and (un)documented). 
At least AEL is a step in the right direction (even though it has to 
adapt itself to the ugliness that exists below..)

BarZ

Steve Murphy wrote:
> 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
>
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> --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