[Asterisk-Users] RE: What about [TCL as ] a higher level configuration language?

Christopher Jacob chris at jacob-solutions.com
Sun Sep 26 19:01:25 MST 2004


This is something that I too have been thinking about. I have worked with a
commercial telephony product in the past that used a variant of TCL (tool
command language) I think it's a great fit for a couple of reasons,

1. Easy, Easy, Easy
2. Refined (TCL has been around and is still actively developed)
3. Easy to extend (I think out of the gate TCL would handle 80 - 90% of what
we needed. And for the other 10 - 20 we could write TCL extensions in C++)
4. Optimization (we can clean up the TCL interpreter so that it's nice and
snappy)
5. Easy

Any thoughts?

~c



Message: 2
Date: 26 Sep 2004 18:38:36 -0600
From: Steve Murphy <murf at e-tools.com>
Subject: [Asterisk-Users] RE: What about a higher level configuration
	language
To: Asterisk-Users at lists.digium.com
Message-ID: <1096245516.20808.1400.camel at lurch.wyoming.e-tools.com>
Content-Type: text/plain

I see some discussion on "higher level config files" -- namely the
extensions.conf

I too, for several months, have been pondering the fact that priorities are
like "assembly language", or the line numbers in old BASIC variants.

I've been thinking and investigating another extensions.conf language, for
which a compiler could be written to convert back to the normal
extensions.conf. The goal would be to get rid of priority numbers
altogether, enforce good programming style (code all the possibilities),
check the arguments to app calls, to make sure they are OK, and other useful
things.

My ideas run counter to a few of the examples provided, and I've not quite
"thunk" thru all the little issues yet, but it looks like a good time to
share at least some of my notes:



1. The new format will have macros, but with named arguments. That way, we
can verify the macro references.

2. The new format will use "blocks", like C, C++, and Java, with curly
brackets {}.

3. The new format will use labels, so Goto commands will go to a label, not
a priority number. Numbers should no longer appear anywhere in Goto's.
Contexts might/might not be necc, as labels could be global.

4. Applications and other commands that skip to new priority numbers will
have syntax, like labeled blocks, for each possibility. It will be a syntax
error to omit these. This forces the user to complete the structure, and
think about what to do in error conditions, so as not to experience gross
failure or strangeness when unexpected results are encountered.

5. The start, timeout, illegal, etc. extensions will be given names. The
illegal, timeout, etc. blocks will be required for each context, at least
that have an extension.




More information about the asterisk-users mailing list