<!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">
Folks,<br>
<br>
This is a nice molehill for me to make a mountain out of...<br>
<br>
There are a lot of diverse ways to control Asterisk -- both initiating
and responding to a call. There's the Manager API. There's the Dial
Plan. There's the AGI. There's the internal C API. Each seems to
provide similar, but not 100%
overlapping functionality of the other.<br>
<br>
The Dial Plan is an interesting beast. I've written a couple of
scripting languages in my time (I reimplemented the 1-2-3 macro
language in a spreadsheet; I wrote a new scripting language in a
spreadsheet by extending the spreadsheet's parsing and evaluation
engine to handle variable assignment, variable retrieval, and
branching; I integrated REXX into a spreadsheet so that REXX could be
the macro language -- the latter was the most robust solution.) It's
interesting to see the organic evolution of a scripting language
happens. It's happening to Dial Plan... it happened to macros within
Lotus 1-2-3 and WordPerfect. Once someone layers GotoToIf and
variable get/set on top of a keystroke replayer, you get a Turing
complete programming language. The problems are (1) nobody wants to
call it a programming language (2) it sucks for doing anything complex
and (3) the longer people shoe-horn complex things into it, the harder
it is to get people to use another mechanism to program their system.
It took Excel and Visual Basic macros to displace 1-2-3's keyboard
macro language, however, at least through Excel 97, one could still run
1-2-3 macros in Excel -- yes, there was a translator that took strings
like "/ssfoo.xls" and converted them into the appropriate Excel command.<br>
<br>
So, how can we all work together to help Asterisk avoid the multiple
API and creeping macro language issues?<br>
<br>
I propose that we form a working group with the goal to unify the
events, state information, the way commands are issued, and the way
extensions are made within Asterisk. 6 or 8 of us spend 45 days
developing:<br>
<ul>
<li>a unified approach to collecting/distributing events to listeners
inside and outside the Asterisk address space</li>
<li>a unified approach to accessing state information such that Dial
Plan, AGI, etc. has access to the same state information that a C
program does (the subject of the original post)<br>
</li>
<li>a unified approach to issuing commands to channels such that an
application, an AGI, the Manager API, and internal C routines all issue
commands to running channels the same way</li>
<li>a unified approach to extending Asterisk such that new events,
state structures, etc. can be added and they become available in the
same way to Dial Plans, etc.</li>
</ul>
The end goal would be the ability to plug a Python or Perl interpreter
into Asterisk and have the Python or Perl script run in parallel with a
Dial Plan rather than being called out from the Dial Plan.<br>
<br>
Asterisk is a totally cool system. Helping it to mature based on what
a lots of people have learned over the years will make it an even
better product.<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
<br>
David<br>
<br>
PS -- I've had a lot of experience with complex systems that have long
lifespans over my career. Back in 1989, I wrote the first UNIX (well,
SCO XENIX) device drivers for Dialogic boards. I also wrote drivers to
do credit card authorization from a UNIX box to one of the two main
authorization systems. I integrated those pieces to build an IVR
system that allowed people to do operator less ordering of products --
a big thing back in '89. I also built a broadcast fax system that
could send 50 simultaneous faxes, each with customized cover pages.
These systems were integrated to allow people to order different online
fax newsletters that would be delivered by a certain time each
morning. In 1992, I founded Athena Design which produced the first
spreadsheet application used in real-time financial trading. I wrote
all of Mesa. Mesa real-time trading users included Swiss Bank, London
Stock Exchange, and Solomon Brothers. That's not to mention other
customers including Chrysler Financial (every car and truck leased
through Chrysler financial from 1993 through 1996 had its numbers run
in the spreadsheet I wrote.) Athena released products for OS/2 as
well. In 1996, I did an Internet startup that was acquired by CMP
media (publishers of InfoWeek.) I became CTO of their largest Internet
site -- NetGuide Live. NetGuide had the 11th highest traffic of any
site on the Internet in 1996 and it was one of the five sites linked of
the Microsoft search page. At NetGuide, I was the first large WebLogic
customer (this was before the BEA acquisition and WebLogic was 6
guys.) In 1998, I released a server-based Java version of Mesa. It
was the worlds fastest spreadsheet (as benchmarked by Sun.) It used
multiple CPUs on an SMP machine to break the calculation task down. On
a 32 CPU SPARC box, it could recalculate an 8,000,000 position
portfolio in real time -- something that no other spreadsheet and few
custom applications can do, even today. In 2000, I architected a
Java-based, web services powered, consumer portal for HP. The
requirements included the ability to sustain 4,000 hits per second on
the portal. In tests, the system was able to sustain the load. Most
recently, I was CTO and VP Engineering of an Internet application
security company. While I haven't done telephony in a number of years,
I do have a history of designing high performance, scalable systems
used in complex enterprise environments.<br>
<br>
John Todd wrote:<br>
<blockquote cite="midp06020411bd47b7f8ba4f@loligo.com" type="cite">At
9:27 AM +0200 on 8/17/04, Holger Schurig wrote:
<br>
<blockquote type="cite"> > Technically, it is possible to write a
daemon that sits on a manager
<br>
<blockquote type="cite"> port and watches for all traffic it sees.
Extracting channel data is
<br>
then quite easy since you can basically execute any command from the
<br>
manager interface.
<br>
</blockquote>
<br>
The python script "manager.py", which I wrote, does exactly this. It's
<br>
opens a manager port and watches everything and updates internal
<br>
representations of channels, registry and voicemail messages. Althought
<br>
manager.py can execute commands, this is not really needed to get all
<br>
channel status. You just have to sit, watch, parse and sometimes to
<br>
rename things.
<br>
<br>
manager.py is part of DeStar, but it works standalone as well.
<br>
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.holgerschurig.de/destar.html">http://www.holgerschurig.de/destar.html</a> or
<br>
<a class="moz-txt-link-freetext" href="http://www.holgerschurig.de/files/destar/">http://www.holgerschurig.de/files/destar/</a> for downloads of snapshots
<br>
</blockquote>
<br>
Holger -
<br>
It sounds like that manager.py is useful in certain circumstances,
but it does not easily allow integration of these variables into the
diaplan, and it also doesn't have the ability to see most of the
variables that I describe which are currently reported with 'show
channel <chan-name>'. I don't know if you mentioned this script
as a solution for the idea which I proposed, but if so, I think they're
not solving the same problem even though some of the features look
similar.
<br>
<br>
JT
<br>
_______________________________________________
<br>
Asterisk-Dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Asterisk-Dev@lists.digium.com">Asterisk-Dev@lists.digium.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
<br>
To UNSUBSCRIBE or update options visit:
<br>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
<br>
</blockquote>
</body>
</html>