[Asterisk-Dev] Dialplan syntax changes.. Option: work on aradically different design..

[Steve Kann]

Matthew Butt wrote:

>Being new round here and maybe talking out of line - it's all well and
>good having a language-based syntax with appropriate constructs - but
>also consider that there will be many people trying to use Asterisk who
>are NOT up to speed with such syntax.
>
>I would guess that most of the Asterisk installers/maintainers out there
>are not developers.  Don't make it harder for the majority!
>
>(PS I'm a developer so anything's good for me :))
>  
>

I think what has been discussed on the "996" call today was something 
like the following (this is really just throwing ideas out there, and I 
think everyone thought it was post-1.2 work):


1) Replace "extensions.conf" to "extensions.js". Extensions.js uses 
(obviously) JavaScript, which is a tidy easily-embeddable procedural 
language.

This requires a bunch of design, but changes that we're already doing 
which de-couple the rest of asterisk from the syntax of the dialplan are 
really all that's needed.

The flow of a call is then defined procedurally, and the core and apps 
expose methods you can use:

// here you can define your extensions. This function takes an 
"extension" number, and returns an Array of destinations. This is just 
one way of doing this of course, you could just do an array

var Extensions = {
0: ["IAX2/operator"],
100: ["IAX2/ILuvAsterisk"],
200: ["IAX2/sales1", "IAX2/sales2", "IAX2/sales3"],
}


// Define a custom Dial wrapper
function MyLocalDial(Call, extension) {

// CDR is a resource that exposes the method add
CDR.begin(Call, Extension); // log this call

// look up the extension in the array defined above.
var dest = Extensions[extension];

// If the extension isn't defined, we can do something here, maybe 
default to
// something, or whatnot. Or maybe throw an exception.
if(!dest) throw "UNAVAILABLE";

try {
Call.Dial(Extensions[extension]);
} catch (e if e == "CONGESTION") {
// maybe try calling somewhere else?
} catch (e) {
Call.Play("unknown-error");
} finally {
// always finish up the CDR
CDR.end(Call, Extension);
}

}

// main entry point?
function DialPlan(Call, context, extension) {
switch(context) {
case 'incoming':
MyDial(Call,extension);
break;
case 'outgoing-restricted':
if(!extension.match(/\d\d\d\d\d\d\d\d\d)) {
// not permitted case.
}
// fall through
case 'outgoing-unrestricted':
OutgoingDial(Call, extension);
break;
default: // unknown context
// do something
break;
}
}


This seems like it can be pretty powerful, and also a heck of a lot 
easier to write, read, and maintain than the complicated nested 
punctuation -tangle we have now.

For "newbies", what we can be easily done is to write code in _this_ 
language, which will read and parse a declarative dialplan, which will 
be much simpler to use. (by declarative, I mean, read a table of 
extensions and options, etc -- something like what the dialplan _used_ 
to be.


I think that the main problem that's happening now, is that the language 
of the dialplan doesn't know what it wants to be.



>MattB
>
>
>-----Original Message-----
>From: asterisk-dev-bounces at lists.digium.com
>[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
>alex at pilosoft.com
>Sent: Wednesday, May 18, 2005 10:41 AM
>To: Asterisk Developers Mailing List
>Subject: Re: [Asterisk-Dev] Dialplan syntax changes.. Option: work on
>aradically different design..
>
>On Wed, 18 May 2005, Brian West wrote:
>
>  
>
>>>What is the dialplan?  It's really a procedural language, it seems.
>>>
>>>Do we already have well defined syntax(es) that would fit?
>>>
>>>Sure we do -- and most of them stem from the syntax of C in one way
>>>      
>>>
>
>  
>
>>>or another.
>>>
>>>So, can it make sense to make the Dialplan look more like C?
>>>      
>>>
>Finally someone who has enough sanity to recognize that line-based 
>programming languages died away with ol' GWBASIC and FORTRAN-1945
>
>I'm for it with both hands.
>
>Now, let's discuss the BNF of the new language. Also, discuss whether we
>need gotos, etc, etc - and whether possibly adoption of another existing
>"domain specific language" would be preferable to rolling our own,
>writing
>parsers and syntax/semantic analyzer, variable/array/etc support code 
>- which needs to be debugged etc. Very boring stuff.
>
>What should be language like? C? Perl? I venture to say, it should be 
>closer to perl, as far as dynamic variables, loose typing and array/hash
>
>support.
>
>Also, question this: If we are going to move toward perl-ish language
>for
>dialpan, do we need really dialplan? Would integrating, say, perlagi
>with
>asterisk in a way mod_perl (as in, no overhead) is integrated be able to
>replace dialplan altogether?
>
>
>
>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>  
>