[Asterisk-Dev] Dial Plan, Scripting, and embrasing other technologies (was: Wish List / Brain Storm from AstriCon)

[David Pollak]

Guys,

I know I sound like a broken record, but...

Continuing to develop a scripting language is a really suboptimal idea.  
It's suboptimal for a number of reasons:
-- Only people who know Asterisk will know the language, thus one would 
have to learn an additional set of stuff to be good with Asterisk and 
the ability to grow the popularity of the platform decreases.
-- A lot of people spend a lot of time developing and enhancing existing 
languages, writing libraries for them, etc.  It's better to build off of 
their work rather than having to duplicate the time and effort they put 
into building those things.
-- The only thing I can see in Dial Plan that is Asterisk specific is 
the selection of an extension by pattern matching for the first line of 
execution.  Other than this dispatch, all other functionality is just 
library calls (app invocations).  I'd rather do the dispatch using an 
SQL query and store the script that executes as a CLOB in my database 
anyway.  Thus, there's no reason to develop a proprietary scripting 
language if it doesn't have any features that make it unique.

So, it seems that the choices are (1) doing a little extra work now to 
create a scripting API and integrate Python, Perl, JavaScript or some 
other common scripting language with the Asterisk distribution so lots 
of people can write dial plans in a language they already know so they 
can do more cool things with Asterisk sooner and can take advantage of 
all the cool libraries, debuggers, IDEs and books that exist for those 
scripting languages or (2) continue to spend a lot of time and effort 
cobbling together extensions to the worst language since BASIC on the 
TRS-80 and creating a scripting language that nobody outside of the 
Asterisk community knows so we can make sure that none of the 
undeserving folks who won't take the time to learn how to do things the 
Asterisk way can keep out of our sandbox... whoops... was that too harsh?

So, with most any language runtime that supports managed memory, there 
will be occasional execution halts while the runtime cleans up unused 
resources (e.g., garbage collection.)  Depending on a lot of factors, 
that execution burp could be 5ms, 10ms, 20ms or 50ms.  While that rules 
out having the script executing on the same thread as the media layer, 
it doesn't mean that the script engine is blocking on its thread as long 
as there's nothing on the media thread that's blocking on input from the 
scripting engine.

Put another way, as long as the media thread and the script thread are 
separate, there's no reason why Python's execution engine couldn't be 
used.  Yes, the scripting engine may not be real time, but the parts of 
the system that have to be real time can be real time.

I mention JavaScript because it's a popular, well known language in the 
web development (client side) community.  As we build IVR applications 
that go beyond simple PBX functionality, we may want to start looking at 
the work the W3C has done in the voice application area.  JavaScript 
(a.k.a., ECMAScript) is the scripting language of choice for W3C specs.

Asterisk is the coolest piece of open source software I've seen since 
Apache.  It's really powerful and really stable.  However, it's its own 
island.   I'd strongly suggest now that Asterisk has turned 1.0, it's 
time to embrace external standards including a standard scripting 
language.  Let's stand on the shoulders of giants and use some really 
cool, really powerful, really popular external pieces to take Asterisk 
to the next level.

My 2 cents.

Thanks,

David

Holger Schurig wrote:

>>I have to say though, I really do like the idea of Asterython. Holger,
>>what do you say? Whose ego do we have to massage to get an Asterython
>>dialplan scripting engine started?
>>    
>>
>
>I like Python as a language, but from what I know is Python not that 
>suited for threaded applications because of some internal equivalent of 
>the "Big Kernel Lock", it's just called "Global Interpreter Lock".
>
>See the first paragraph at http://docs.python.org/api/threads.html
>
>If all the interpretation is done in one thread, as suggested before, this 
>is not a problem. However, when we want to have scripts running while 
>connected, then I fear that one thread is not enought and would become a 
>bottleneck.
>
>
>If we ever want to use something different, we need to think about:
>
>a) Extension (e.g. Pattern) matching, including support for early-dial
>b) keeping Contexts?
>c) inclusion of other routines?
>d) do we want Goto's inside the sections, e.g. with local labels?
>
>So, maybe something comes out that does not resemble on of the current 
>scripting languages, but is still nicer to write/debug/recode.
>
>
>Maybe we look at SER scripts or Bayonne scripts to get ideas ...
>
>_______________________________________________
>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
>  
>