IO definitely looks like a candidate. We were looking at Erlang as well since it was designed to operate in a switch and is asynchronous. The important thing that I have found developing IVR and PBX applications is that there are two aspects that are very similar to creating GUI programs.
One defines a structure (like a window), what controls it has and then defines what events it responds to. Second there are the actions and responses taken when those events arrive. A purely programmatic approach requires someone to write a program that creates the structure (like IVR menus and prompts). Too verbose. A purely definition-oriented approach limits what can be done with logic and code flow. Too rigid. There needs to be something high-level to describe menus and prompts and states so that a non-programmer can create them. This would allow a kind of code and audio review at the beginning. Then code can be put in at any time to respond to events and do processing. This also allows GUI tools to be created a lot easier. I work with some systems here that demonstrate the wrong way to do programming. The best I can describe is that they are virtual punch-card simulators. They try to do entire program flow and logic with a GUI and it fails because anything more complicated than a 3-step IVR turns into a mess and takes hours to debug. The Asterisk dialplan carries that baggage as well. On Wed, 2006-03-22 at 00:53 +0900, bkml wrote: > On Mar 21, 2006, at 9:04 PM, Bartek Kania wrote: > > > There has been talk of replacing the dialplan with something good and > > beautiful. > > I think benjk has some examples online (but I forgot where). > > it's at http://www.sunrise-tel.com/asterisk-plist-support.html > > and you need to scroll down a little to where it says "The Asterisk > Dialplan" > > HOWEVER ... > > keep in mind that this is not a dialplan language but a meta language. > > That is to say, the meta dialplan is only for two things ... > > 1) define named patterns for pattern matching > > 2) define which pattern(s) will trigger which dialplan script(s) > > the dialplan scripts itself would have to be in some suitable > dialplan language. The meta language does not concern itself with > anymore than match and dispatch. > > Under this model, dialplan scripts can be in different languages > using different plug-ins and they can be either embedded or stored > externally in flat files or in a database. > > A default dialplan engine and storage method can be defined, so that > if nothing is specified, all dialplan scripts would be in the default > language and storage method, for example ... > > default = { > engine = "asterisk_1.0"; > storage = "inline"; > }; > > ... would provide legacy support for every context in which no engine > and no storage is specified, mimicking the same dialplan behaviour > that we have now. > > Under this model it would be possible to write an AEL2 plugin and > then specify that as an engine for some or all contexts, however, as > I said before, I think we should first look elsewhere before > considering development an AEL2 plug-in. As Daniel said, it would > seem an unwise use of our resources to do so, at least for the time > being. > > I personally have hopes for the IO language to be a suitable dialplan > language either as it is or as a base that can be mended into a > suitable dialplan language. In particular, it promises to take care > of all the performance issues various people have raised with the > current dialplan engine and alternatives. > > for further reading, the IO website is at > > http://www.iolanguage.com > > regards > benjk > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > voicemail http://uk.messenger.yahoo.com > _______________________________________________ > Openpbx-dev mailing list > [email protected] > http://lists.openpbx.org/mailman/listinfo/openpbx-dev _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
