Hi Beau and OpenPBX friends, On Tue, 21 Mar 2006, Beau Hargis wrote:
> > The big issue is that Asterisk doesnt have any concept of asynchronous > events being in control by a dial plan. Looks like OpenPBX still carries > that baggage. IVRs and PBXs are by nature asynchronous. To do something > in Perl, or any other language, I have to write wrappers and libraries > to do things in such a way to make control the behavior of the system. > Very true, but an even bigger issue than asynchronous events: the extension logic needs to follow the rules of a well defined finite state machine. For example, it should be impossible to hang up a channel twice in the system [ for a channel that is already hung up, calling ast_hangup twice will free a pointer twice causing a seg fault], or to run an app after the line has been hung up [ because this could cause a channel dead lock]. Imagine the problem of anything being able to call ast_hangup twice -- asynchronously!!! "oh crap!" is right! :) The whole system needs to implement a basic FSM. You would agree with me if you had to write a 20-30 page res_* IVR application! :) > In my opinion, OpenPBX needs a whole new concept of a dial plan not > plug-ins for it. The way Asterisk does it is hideous and the > implementation is horrible and unscalable. > I absolutely agree. I have been working on enhancements to Tony's res_js that I hope to commit to OpenPBX soon. I am hoping to reach this point soon after the .2 release? I am looking to move to an all res_js-based-pbx solution based on my branch "openpbx-lite" which I want to suggest we try using Tony's pluggable PBX module as the only core. ( again see openpbx-lite in my branch .. its a start, no makefile yet) You will be pleased to know that I have implemented various asynchrous eventing into res_js using pthread. But my C skills are not "expert level" so it is going to need a lot feedback and work to be done right. I spoke with BenJK on irc about how I implemented the async eventing and he disagreed with using pthread because they were too heavy -- which I disagree because dial plan logic does not need to be extremely high performance ( who cares if it takes an extra 10 ms or even 100ms for a pthread_cond to propagate throughout a call -- you can't enter DTMF that fast anyway). In terms of being scalable, I believe the pthread approach is very scalable. .. for example it should be OK to run 1000 threads on a single processor. If a call takes 3-4 threads(!), that is a good 250 calls per CPU. Don't forget we aren't even talking about thread pools yet, we could reach the hardware IO limitations way before pthread overhead would bite us. I took a look at the Io language and didn't see anything that could not be done with Javascript. (Yes javascript has concurrency (think any modern day browser and AJAX applications like gmail or Activescript/Flash [yup.. Flash uses spidermonkey]) and supports libraries and modules like OpenGL, SVG and XML [google for egachine, Spidermonkey 1.6, and javascript and swig] ) I was surprised to learn that Erlang was developed for telecom switches! >From what I understand, Io is directly based from Erlang ( as well as others). I think it would be a great idea to use Erlang for a PBX if you were in a project like freeswitch.org. I also looked at plist, pointed out and heavly worked on by benjk. I think JSON is a better approach than the plist -- because it allows you to use constructors inside of a JSON object which gives you a dynamic OO feel needed for some business objects. Good news is benjk work is very very similar to JSON from what I can tell. Can we use these efforts? I hope so!! BenJK has some pretty nice code on his website for configuration file format! Benjk pointed out that plist and JSON are related in syntax, and that plist is/was a creation of NeXT software. It looks like JSON and plist are very closely related because they are both based on the NeXT toolkit architecture. (Where plist is a direct descendent of NeXT software, and JSON appears to be an indirect descendent of NeXT via the first WWW browser/server being on NeXT, netscape Corp, their javascript, then finally EMCA script 262 --- or maybe its a very very big coincidence. oh well) I like the idea of res_io but I beleive res_js is still a better solution. What am I missing? -D "Everybody talks about the weather but nobody does anything about it." Mark Twain _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
