On Thu, 17 Aug 2006 04:02:15 +0400 , Jean-Michel Hiver wrote: > On Wed, 2006-08-16 at 18:30 -0700, asterisk-users- > [EMAIL PROTECTED] 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ --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
