[asterisk-users] Re: what is the real use of AEL?
Steve Murphy
murf at digium.com
Wed Aug 16 23:42:14 MST 2006
On Thu, 17 Aug 2006 04:02:15 +0400 , Jean-Michel Hiver wrote:
> On Wed, 2006-08-16 at 18:30 -0700, asterisk-users-
> request at lists.digium.com wrote:
> > >Steve Murphy joined our development team at the beginning of June. Steve (murf on IRC/Mantis) had rewritten Asterisk's expression parser and the AEL language parser as a volunteer community member, along with various other bug fixes and improvements.
> > >
> > >
> > Which makes me think, what is the real use of AEL. I have taken a look
> > at it, and it makes asterisk's config file almost as unreadable as SER.
> >
> > What exactly does AEL do that a well written AGI / FastAGI app doesn't?
> >
> > I would think (but I'm surely wrong) that it would be better to do work
> > on having well defined APIs that allow us to script Asterisk (such as
> > AGI and the Manager interface) rather than invent Yet Another Pseudo
> > Programming Language - which is going to be an endless task... Don't you
> > think?
> >
> > That being said, just like the rest of the community, I'm very happy
> > with Kevin's exciting announcement!
> >
> > Cheers,
> > Jean-Michel.
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!
(For those of you who don't have any idea about what this discussion is
about, find out all about AEL via the web page,
http://www.voip-info.org/wiki/view/Asterisk+AEL2 )
Many thanks to rushowr for his reply in my defense as pertaining to
speed and readability. Actually, it might be interesting to get a
handle on the real speed of the AEL extension engine vs. the AGI program
at the other end of the pipe. Here is a little AEL script:
context sppedtest {
771 => { // Get the PIPS (priority instructions per second)
// for your current asterisk box.
// perform this on quiescent asterisk box --
// "all your CPU cycles are belong to us"
iterations=100000; // Choose iterations wisely--
// around 10 sec. of execution time
// is good, gives good granularity.
Set(time1=${EPOCH});
for(i=1; ${i} < ${iterations}; i = ${i} + 1)
NoOp(Hello);
Set(time2=${EPOCH});
Verbose(The time diff is $[ ${time2} - ${time1} ] seconds);
Verbose(Which means that the priorities/sec = $[ 4*${iterations} /
(${time2} - ${time1}) ]);
SayNumber($[ 4 * ${iterations} / (${time2} - ${time1}) ]);
}
}
The above compiles into this extensions format:
exten => 771,1,Set(iterations=$[100000])
exten => 771,2,Set(time1=${EPOCH})
exten => 771,3,Set(i=$[1])
exten => 771,4,GotoIf($[${i} < ${iterations}]?5:8)
exten => 771,5,NoOp(Hello)
exten => 771,6,Set(i=$[${i} + 1])
exten => 771,7,Goto(4)
exten => 771,8,NoOp(Finish for-workext-48)
exten => 771,9,Set(time2=${EPOCH})
exten => 771,10,Verbose(The time diff is $[${time2} - ${time1} ]
seconds)
exten => 771,11,Verbose(Which means that the priorities/sec = $[4*
${iterations} / (${time2} - ${time1}) ])
exten => 771,12,SayNumber($[4 * ${iterations} / (${time2} - ${time1}) ])
(Please remember that email packages break lines where they shouldn't be
broken for extensions.conf format to work!)
Stick the 771 extension into a context where you can dial it. Play with
the iterations number until it runs roughly 10 seconds or so. Do it on
a quiet, unloaded asterisk box. The goal is to get the biggest number
you can in the 10 or so seconds. Set your Verbose level to 0. You don't
want a hundred-thousand log entries.
Now, rewrite the above into an AGI script. You'll definitely be able
to run the loop math faster, I'd bet. But... well, just see. My little
1.8Ghz machine runs at 83k PIPS. A 64-bit dual processor monster ran at
roughly 200K PIPS. I'd be very interested to see what kind of
performance an (exactly) equivalent perl AGI, or PHP AGI, or even a
straight compiled C program would get in this case. They should all be
much, much, much faster, right? Orders of magnitude faster? My guess, is
maybe 3 or 4 times faster at the most, but... well, try it and see. Just
make sure that the NoOp(Hello) gets executed in asterisk, OK?
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!)
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. 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.
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. 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.
[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?)]
And lastly, let me add that AEL is ***NOT*** meant to replace AGI
scripts! Heaven forbid!! There are a HUGE list of things that AEL could
never do, that AGI scripts can do easily. AGI scripts are just another
app call that AEL can execute. If you hate AEL, write most of your
code in AGI,and call it from AEL. At least you'll get some small
benefit from linting what small amount you did in AEL vs.
extensions.conf.
Sure, if we sit down and completely rewrite a large chunk of the core of
Asterisk, we can completely get rid of extensions.conf and AEL, and
we could use pure AGI to do everything. And if AGI doesn't give us the
performance that we need, they can be recoded into apps and compiled and
loaded with the other apps/modules. But it is hard for me to imagine
that the AGI's would be easier to read, more concise, than AEL or
extensions.conf format, for that matter. I say, every language has its
domain, and its advantages in that domain, and AEL may have its
problems, but it comfortably takes it place in the dialplan domain.
Another thing we could do is rip out all the control flow stuff out
of AEL and the extensions.conf, and force all app calls and logic to be
in AGI scripts instead. The trouble with that would be that we have to
open other files, multiple files, to understand even the simplest
dialplan. This wouldn't aid understanding, complexity, or readability.
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...!
Is this an argument either of us will win? Who knows. Evolution of
Asterisk is progressing at a rapid pace. Maybe in a couple of releases,
some neat new idea will pop up and change the whole language landscape,
and obsolesce both AEL and the whole idea of AGI's. We'll see. All I
know, is that at this moment, in my mind AEL beats the heck out of dial
plan programming in extensions.conf format. I've personally never felt
an urge to replace simple dialplan procedures with AGI scripts just so I
can do it in my favorite scripting language.
And, pardon the shameless plug here, but for all you fence sitters, I
invite you to try AEL in/for your dialplans, and give me feedback! If
the majority of those who use it feel it's useless, I'll drop it and do
other useful things for Asterisk-- there's plenty to do!
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/20060816/1067ce66/smime.bin
More information about the asterisk-users
mailing list