[Asterisk-Dev] TCL for configuration?

[Steven Critchfield]

On Mon, 2003-06-23 at 01:15, Reed Wade wrote:
> At 12:04 AM 6/23/2003 -0500, Steven Critchfield wrote:
> >On Sun, 2003-06-22 at 22:27, Reed Wade wrote:
> > > Call me crazy but does anyone else think TCL scripts might provide a 
> > cleaner
> > > configuration mechanism than the existing config file format?
> > >
> > > I haven't been around Asterisk enough to say but it looks to me
> > > like the config format was devised before something like TCL
> > > would have been needed--but it's now grown such that a cleaner
> > > mechanism to provide variables and expressions would be pretty useful.
> >
> >Why should you script somthing that is mostly lookup???
> 
> 
> 
> A more intuitive variable and expression evaluation syntax would
> make the config easier to maintain.

This could be fixed/upgraded in the current applications that are being
used.

> True looping constructs could solve a lot of what has to be done
> with macro expansion now.

Macros are not specifically for looping. They are for shortcuts in
writing. Macros are suppoed to be an easy way to define someones default
extension config, then just pass the macro the extension number and the
channel to use and the rest is done on the macro.

> One option would be to use TCL only to represent a static config.
> The script would be evaluated at start up and reload.
> 
> An additional option could be to allow TCL procedures to register
> themselves as Asterisk apps.

So you can do this somewhat with AGI. 

In fact, for you do flesh out your idea, you might want to write your
tcl app as an agi script that happens to insert all the extension logic.
Then your standard config could just be a agi call that you would make
to run the tcl script. 

> > >From what I know, the current configs where developed as a easy way of
> >getting the data up from a file and into a C memory structure. From the
> >code itself the speed of looking up the extension logic must be kept
> >FAST.
> >
> >Just would like you to think your idea through a bit more and see if you
> >could see the way to making at least as feature rich a setup.
> 
> 
> There shouldn't be a loss of features or performance. The TCL
> script would cause to be created the same fast running data
> structures in use now.

except that a syntax error would cause the script to fail and asterisk
to not start.

> It should even be mostly possible to take an existing (non TCL aware)
> Asterisk config file and have it parsed by the TCL interpreter.
> "exten" would become a command, ";" could replace "#" as the comment
> indicator, "[" at the start of a line could be given unusual meaning
> (not desirable, but doable).

The current comment indicator is the semicolon, it is this way do to the
fact that a # is a legitimate digit for extensions.

> Variable assignment ("set a 23" instead of "a=23") will be annoying or
> required special coding.
> 
> So, backwards compatibility would probably be necessary and could
> be done but you'd want to step away from it as soon as possible.
> 
> Aside from simpler and freer config files, it looks like a lot of parsing
> code could be dropped from the Asterisk core and from individual applications
> like voicemail. This is bound to make it simpler to manage the code base
> going forward.

Simpler? How many users do you expect to know how to program in TCL?
You'd be better off trying to get the users to learn perl, but then the
chances that a person would get something wrong is very high.  
-- 
Steven Critchfield <critch at basesys.com>