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

[Tzafrir Cohen]

On Wed, May 18, 2005 at 02:47:21PM -0400, Steve Kann wrote:
> 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.

any example of something other than a web browser that supports an
embedded emcascript/javascript?

Developers are familiar with that language. Yet it has not become
popular. On my debian system I only found:

  ngs-js: 
	  an independent JS interpeter. No other package depends on it
	  ot its library

  entity-javascript:
	  A GUI builder. Has javascript bindings in addition to bindings for
		perl, python, TCL and C.

Compare that to the use of perl, python, tcl and lua.
I'd say most folks don't consider javascript a good language for that
task. I personally wrote very little javascript and when I did, I didn't
like it. But it was long ago.

Another point: how can the dialplan be manipulated by anything outside
of the asterisk process? running 'asterisk -rx something' just to help
parse a complicated dialplan is probably a mess.

Another point: how exactly are you going to debug that code? What will
it take to add something like apache's configtest to know that your
changes were not harmful before you run 'reload'?

> 
> 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;
> }
> }

It seems quite verbose. You'll need much more text to express a simple
dialplan of today.

> 
> 
> 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.

You think too procedural. This code will be just as difficult to
uderstand once you have several many entry points and a complicated
state (kep for each channel separately).

How do you override parts at run-time? What's the run-time overhead?

> 
> 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.

The current dilplan is actually quite declerative, unlike the procedural
option you suggest.

> 
> 
> 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.

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen at xorcom.com  http://www.xorcom.com