For a while now I’ve been toying around with the idea of utilizing Lighttpd for various web based applications. One of these application is my Automatic Dialer framework, also known as the GTD-API. The main issue with the GTD-API (besides that it is highly reliant on a MySQL database), is the fact that all requests have to be processed via XML-RPC HTTP post requests.

The main issue that I had was this: in a production scenario, a dialer management system will generate over 100 requests to the XML-RPC server. While Apache is fully capable of rendering services at such a speed, its increasing size and boilerplate automatically introduce a management issue. In addition, as I was trying to build a dialer appliance that can be used in any enterprise, the ever expanding Apache wasn’t a good choice.

While I was looking at both NginX and Lighttpd, the latter captured my eye, thanks to a simple advantage – The integration of FastCGI based PHP was so easy, that it almost troubling that I used Apache all these years.

At this point, once I got Lighhtpd working with my Dialer, I said to myself: “It would be really cool to go about and send status reports back from the dialer, directly to the web client activating the call. In addition, I really don’t want to go about and perform these updates to the database, then query the database – that would, literally, kill the MySQL server.

So, I implemented a local session storage area for each call, which updated the call status as it traverses. The information was stored on the hard drive, which allowed a better response time than the ever indexing MySQL server. The status reports were picked up from the Lighttpd server via an Ajax client (which I didn’t write – I suck at JS) – and it works quite well.

I wonder, can Lighttpd completely replace Apache? … time will tell…

Lets put it this way: I am no web developer, nor was I ever, nor will I ever be. While I do enjoy playing around with various web designs and web technologies, I’m no web developer. Think about it, this blog is based upon the WordPress system, which means, that while I could easily build my own blog system – I didn’t.As most developers are, I am a lazy person – when it comes to writing code, that is. This means that when I write an application, I really like spending my time working on the application logic, rather than wasting my time on GUI. I’ve always looked for better ways to improve my applications development track, especially, the ability to seperate the logic from the display in such a way that both become agnostic to one another. So, I started looking into various MVC (Model-View-Controller) frameworks – which had been springing up all over the past year.

While the most popular one seems to be Ruby-On-Rails, I don’t like Ruby and prefare PHP. Various options exist here, so I seeked one that was easy to integrate and that is backed by a company of some sort.

Zend Framework

Much like PHP, Zend Framework appears to be a mixture of functions, closely wrapped into a set of classes, to help you create an MVC environment. I’ve started learning it, and shortly came to a conclusion: much like PHP, Zend Framework enables you a feature rich environment, however, it isn’t always clear how to get to do something with it.


CakePHP appears to be a slightly more rigid PHP MVC environment, with a fairly vibrant and lively community backing it up. However, like any other young community backed project, it lacks one main element: proper documentation. The documents available on the website are sketchy at best, which means, there is no ordered manner of getting started fast with CakePHP.

Code Igniter

Code Igniter is a PHP MVC environment, backed by Ellis Labs – the same people behing Expression Engine. So, from a technical point of view, this is a plus, as Ellis Labs had made it its business to make Code Igniter a valid product. The amount of information available on the Internet is satisfactory, and the documentation on the website is more than good – it’s down right GREAT! The addition of video tutorials with a very clear naration enables even a novice developer to go about and start working fast with Code Igniter. The one thing that Code Igniter lacks is a rigid framework, which means, that just like PHP – it’s easy to fuck about and mess things up.

My Choice

Currently, I use a mixture of Code Igniter + Prototype + XAJAX to build my web applications, which makes for a fairly rapid development environment – I’d love to hear what you have to say about these.

It always amazes me how fragile our body really is. For those of you who had met in person, you know that I’m a fairly bulky guy – which means that I’m slightly larger than most people. In any case, there is nothing more frustrating than throwing your back – it’s the most annoying thing ever.

Throwing your back is somewhat like having an invisible fly hovering next to your ear, you can hear it, but you can’t swat it! A thrown back is just the same, you are perfectly fine in every other aspect, but you can’t do anything because you are STUCK!

I’m writing this post from bed, and believe me, as much as that sounds inviting – IT ISN’T!

As most of you reading this blog, you must know that I’ve published an AsteriskNOW book early this year. I’m happy to say that I’ve received numerous emails since the publication of the book, all asking various questions about Asterisk in general and AsteriskNOW in particular.

Most of the questions that I received were related to the development of AGI and AMI scripts, and how to utilize Asterisk as an application layer platform. This inspired me to work on additonal title, to complete my previous book. I’m currently working on an Asterisk Developers guide, for AGI/CTI development with Asterisk. The book serves as a complete guide, summarizing the various aspects of developing AGI/CTI applications with Asterisk, while, enjoying various additions from my day-to-day experience with AGI/CTI development with Asterisk. The book is written as an eye-opener for experienced developers, wishing to make their transition to AGI/CTI development, and teaches them how to avoid the most common mistakes of early day AGI developers.

I’ll be be updating the blog with my progress. Currently, chapters 1 through 5 are complete, covering the basic aspects of dial-plan and AGI development. More information will be released soon.