<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Making the assumption that all scripting languages can compile down to
Perl's new Virtual Machine I think constrains the discussion. I'd much
rather see a scripting API rather than a built-in scripting language.<br>
<br>
But, at a higher level, this might be the right time to think about the
larger architectural issues in Asterisk. Asterisk treats media stream,
signaling, and "applications" in a similar manner and often handles all
of them on the same thread. This is, over the long term, a Bad Thing
(tm). There should be different layers (that run on different threads)
in Asterisk that handle different tasks and have different semantics.
For example:<br>
<ul>
<li>Media layer: a source and sink model where media stream are
handled as sources for other stream and sinks that get connected to
sources. These stream would generate events that indicate out of band
information (e.g., DTMF tones, end of stream events, etc.) The streams
would accept a very simple set of commands: open, close, start playing,
connect, disconnect, mix</li>
<li>A signaling layer: dealing with normalizing signals (e.g., SIP
Invite, SIP Reinvite, etc.) into a set of events that look the same to
the higher level within Asterisk, but with extra protocol specific
information.</li>
<li>A command layer: deals will dispatching events from the signaling
and media layers and generating commands into the the signaling and
media layers. The command layer would run on a separate thread so as
not to block the signaling or media. The command layer would be a
unified set of commands in a single place. Compiled-in applications
could be written at this level (so MeetMe doesn't have to worry about
doing media mixing, for example) and external applications can
communicate at this level as well (it's a simple matter to translate
the events into text messages -- maybe XML or maybe the HTTP-header
style that's currently being used) and to translate commands into
function calls.</li>
</ul>
In this model, the command layer lends itself to the scripting language
of choice. If it's Perl in the same process as Asterisk, cool. If
it's C# in a process running on another box, cool. They all go through
the same interface and all have access to the same commands and events.<br>
<br>
Additionally, this allows the signaling and command layers to use C++
object libraries that do ref counting as to avoid memory leaks (I would
continue to use C and malloc/free at the media layer because this code
has to be as tight, well controlled, and understandable as possible.)
Signaling and command layers don't need to respond in the tight time
frames that the media layer needs.<br>
<br>
That's my 2 cents.<br>
<br>
Steven Critchfield wrote:<br>
<blockquote cite="mid1096473124.11304.27.camel@critch" type="cite">
<pre wrap="">On Wed, 2004-09-29 at 10:36, Benjamin on Asterisk Mailing Lists wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 29 Sep 2004 15:55:56 +0200, Holger Schurig
<a class="moz-txt-link-rfc2396E" href="mailto:hs4233@mail.mn-solutions.de"><hs4233@mail.mn-solutions.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Based on this thinking we would still write code in old BASIC:
10 FOR I = 1 TO 10
20 PRINT "HELLO"
30 NEXT I
But somehow we have now languages without line numbers and we love them
all.
</pre>
</blockquote>
<pre wrap="">I agree, but the trouble is that people are very religious about their
choice of language and I guess Mark is concerned about not letting the
all too often occuring religious fights over languages be carried into
Asterisk. We are all old enough to realise already that no matter what
language you were to implement for dialplan scripting, there will
always be some folks who want it different. You can't really be
everything to everybody. I think Mark is doing the right thing trying
to avoid this.
Having said that, I'd like to emphasise that I am not saying we
shouldn't aim to get something better. However, I don't think the
solution is to modify the existing scripting engine.
Let that whachamacallit? BASTIC ?! stay as it is, perhaps a few minor
improvements here and there, but basically leave it alone.
</pre>
</blockquote>
<pre wrap=""><!---->
So basically we need to look at building Parrot into asterisk so that
all the language plugins and lower level bytcode is already done. It
would allow us a quick route to implementing the dialplan in a language
truely suited to the task... BrainF#ck.....
</pre>
</blockquote>
</body>
</html>