Announcing Astxx, the Asterisk C++ wrapper and utility lib

Does an Asterisk C++ wrapper and utility library intrest you?

  • Yes
  • No

0 voters

Ok Asterisk peeps, just wanted to give everyone a heads up. I am now working on an Asterisk C++ wrapper an utility library. Right now the current development snapshot only contains an AGI wrapper (which should be fairly complete). I plan on adding an interface to the Asterisk Manager API, FastAGI, EAGI (which is probably supported already…), and if possible an actual C++ wrapper around the Asterisk API that would enable you to write Asterisk modules in C++ with out a lot of hassel in a C++ style of coding.

Currently it is not available anywhere online so if you want a development snapshot send me a message. Also if you are intrested in assisting in it’s development let me know as well.

(Note: I am not on the mailing lists hence the reason I did not announce this there…)

Matthew -

That is a great addition that * really needs. I was pondering the same type of thing for java. In the OO world, you would have classes to represent things like channels, calls, invocation context, etc. The framework would do the mundane things like parsing arguments, and present them as an array of objects. This would cut down a lot on the effort required to develop * apps, and would eliminate a lot of opportunity for errors. It would also make it much easier to get up to speed developing apps for noobs.

Do you have any design artifacts? Even if it is just headers at this point. Having early feedback at the design phase can help make any framework better. Also, if we ever have a java framework integrated into *, it would be good to have it and the c++ framework in synch. They could compliment each other and sharing design could improve both.

For the java framework, I could see a separate server providing a container for java * ‘apps’. They would implement an interface and the server would provide a container similar to j2ee for servlets and ejbs (that part is already done and freely available). The server would take care of transactions, threading and resource sharing (jdbc thread pools, access to ldap, jms, etc) and allow developers to focus on appplication logic. There would be a lightweight connector that invokes the apps transparently. Since the server could then stay up, the overhead of creating a new process for invoking * apps would be minimized.

  • Woody

Matthew -

I’m surprised nobody else has shown any interest! Maybe this is just a slow forum. I’d be interested in seeing something. I might be able to lend a hand. I’m new to *, but it looks fairly straightforward for the most part.

  • Woody

I don’t have the code publicly availble yet, but if you want it you can send me an email or a pm and I can send it to you. Currently the AGI stack is the only thing that is functional (or started…).