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.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
