[Asterisk-Dev] Wish List / Brain Storm from AstriCon

[David Pollak]

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.

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:

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

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.

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.

That's my 2 cents.

Steven Critchfield wrote:

>On Wed, 2004-09-29 at 10:36, Benjamin on Asterisk Mailing Lists wrote:
>  
>
>>On Wed, 29 Sep 2004 15:55:56 +0200, Holger Schurig
>><hs4233 at mail.mn-solutions.de> wrote:
>>    
>>
>>>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.
>>>      
>>>
>>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.
>>    
>>
>
>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.....
> 
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20040929/ea2f9869/attachment.htm