[Asterisk-Dev] TCL for configuration?

[Reed Wade]

At 09:28 AM 6/23/2003 -0500, you wrote:
>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.


yes, but loops and conditionals would be a more fun way to do that




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


ah!, much cleaner (and easier) than polluting the main config--I like that;
sounds like a good way to find out if a TCL based config really is useful




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


...which would be a good thing, I think



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


yes, that was what I meant; though if one wanted to go whole TCL
it would still work quoted #'s are safe to use



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


for new folks it would be no less more difficult than learning how
to construct config files in the existing format

...and probably a lot simpler than perl, TCL doesn't really exist as a
language it's much more a command parser. The syntax rules really just
come down to "is this a properly quoted string?"

-reed


>--
>Steven Critchfield <critch at basesys.com>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev