[asterisk-users] Re: what is the real use of AEL?

[Jean-Michel Hiver]

>In the above, Jean-Michel puts it right on the table: of what 
>possible use is AEL? Why am I bothering to waste my time with it? It's a
>valid question! It deserves some discussion!
>  
>
First of all I'd like to thank for all the good answers and valid points 
people have made to this question.

><snip/>
>
>Sorry for the diversion. My answer to Jean-Michel's straightforward
>question goes along some different lines than rushowr. I never really
>cared how fast/efficient the extension engine was-- it's obvious I'm
>not writing stuff for thousands of concurrent users like rushowr. But in
>the majority of cases, it's the apps that are run from AEL that take up
>all the execution time. As long as AEL execution time is pretty minimal
>between priorities, it's probably going to be OK. (users of dialplans
>for intensively loaded sites may HIGHLY disagree!)
>  
>
I admit it, I haven't done the test. Using FastAGI is just enough speed 
for me :-)

>My first reason for getting excited about AEL, enough so, to rewrite the
>parser to make it more user-friendly, and add a few bells and whistles,
>was that it provided an opportunity to code dialplans with higher
>level constructs than gotos. Truly, AEL is to extension.conf format,
>as programming languages are to assembler.
>
While I can see that it is a nice thing to have, in my opinion it makes 
"configuration files" look less and less like "configuration files" and 
more like a programming language. And I don't know, I doubt that mixing 
these two things look very good.

Now to be honest, I'll probably be using AEL (assuming it's there to 
stay) for complicated dialplan constructs, but #includes are going to be 
good to avoid having a conf file that looks like a mix of apples and 
potatoes :)

>But, in this, Jean-Michel
>is right to ask: we already have several possible programming languages,
>perl, C, java, PHP, ruby, and so on. The one advantage AEL holds over
>all of them, is that its structure parallels the data model used in
>Asterisk. That data model is composed mainly of contexts, extensions,
>and priorities. Because AEL follows that structure, it is easier to 
>write dialplans than it would be in other languages. Most AGI scripts
>don't have to deal with anything above the priority level... and if
>you do want to generate an entire dialplan from the innards of a perl
>script, I doubt it would easier to read and understand than an AEL
>script, nor do I think it would be anywhere near as concise.
>  
>
That's where I beg to differ. How is the code snippet more concise / 
readable than, say:

    #!/usr/bin/perl
    use FictionalAPI; # imports NoOp, Verbose...

    sub loop {
        my $iterations = 1000000;
        my $time1 = time;
        NoOp('hello') for (1..$iterations);
        my $time2 = time;
       
        my $diff = $time2 - $time1;
        my $prisecs = 4 * $iterations / $diff;;
       
        Verbose("The time diff is $diff seconds");
        Verbose("Which means the priorities/sec = $prisecs");
        SayNumber($prisecs);
    }

That assumes you have FictionalAPI, which is why I highlighted the need 
to clean, well defined API and good IPC communication between Asterisk 
and external systems / program.


>The next reason I spent time on it was code quality. There is no lint
>yet for extensions.conf. We've seen little things like misspellings
>of "exten =>" into "extem =>" silently drop that priority, which may
>take months to spot and fix. Not that a thorough linter couldn't be
>written, but I did add tons of checks to the AEL parser, to spot common
>errors at compile time, rather than find them at run-time in a
>production dial-plan.
>
Now that's awesome. The OCamel language has a pretty crazy type infering 
compiler (i.e. the compiler infers the type of variables from their use 
in the code rather than a declaration) you might want to take a look at. 
This is as good as type checking goes IMHO :)


>Haven't we all taken a course on software
>quality, or read some articles at least? How much do errors cost
>if found at compile time, as opposed to the cost of finding them at 
>run time? The earlier the phase at which errors are found and
>eliminated, the cheaper the error. Right? and so, AEL is a tool for
>you to reduce your costs of generating dial plans. I might add here,
>that other languages also do similar checks at parse time; but some of
>the checks that AEL will do, are specific to the underlying data model.
>You won't necessarily get those kind of checks out of perl or php.
>  
>
Valid point. However, Perl has a nice fix: the Test::More suite and 
things like Mock::Object, which let you write pretty comprehensive test 
suites to do some kind of code quality (any decent CPAN module has a 
test suite...). That being said, you are right, type checking is 
important and it saves time. I wish Perl had Ocamel parser / compiler 
features :)


>[BTW, haven't you ever stopped, after you have finished writing a
>dialplan, just as you are about to put it in production on a live
>asterisk server with tons of users, and asked yourself, "How many errors
>are in this code?" What's your answer? How do you know you are right?)]
>  
>
+1, good point. Maybe some work on the 'regular' parser is needed :)


><snip />
>
>Another option is to pick a good, tight embeddable language like scheme,
>or who knows what else, and embed it directly in asterisk, and use that
>for dial-plan procedure writing. Again, I don't see how it would clarify
>programming dialplans any better than AEL. This might be a win, BTW, in
>that right now, AEL uses the expr parser for $[ ... ] expressions and
>another parser for ${ } expressions (including functions). Switching to
>a new core embedded engine would force us to scrap those in favor of
>some kind of compiled code tree. But try to keep in mind that asterisk
>processes contexts, extensions and priorities, NOT code trees. The code
>trees will ALWAYS be embedded in the extensions, not extensions embedded
>in code trees. Not unless we radically rewrite the whole underpinnings
>of Asterisk...!
>  
>
You are right. Rule #1 is that Asterisk needs to remain Asterisk. I 
don't see the point of completely fundamentally changing something 
that's been of proven reliablity and robustness, unless there is a 
tremendous advantage to be gained (which isn't the case here obviously...)


>Is this an argument either of us will win?
>
I'm not really making an argument, just raising some questions. As a 
user I am indeed happy with all the good work done on Asterisk, and 
certainly not doing any moaning. Asterisk is great. I have some reserves 
about AEL, but who knows - in a couple of month's time I might end up 
being it's greatest fan :)

Cheers,
Jean-Michel.