This is an interesting solution, but I wonder if it was more novelty-based, than a product of necessity. It's true that the chat bot can be decentralized, running from anyone's laptop, to serve incoming requests. However, so could a web application. Sooner or later, it would have to be run from a dedicated server anyway. As far as maintenance, how is a chat bot wrapping the script any easier to maintain than a web app?

Thanks for bringing up the web-app vs chat bot straight away. I did get some questions on these lines during the conference itself. 1) I do not agree that maintaining bots and web apps are the same effort-wise. An IRC can very easily be served of a framework that is event driven in nature -- on the lines of a node.js or eventmachine with barely any additional effort. On the other hand, doing this for a web application would require extensive effort for writing your code the right way and bringing in the right tools like a templating engine. You will build your own framework almost.

2) Since the application is process heavy and take over 45 seconds to serve a request, this would involve extensive tweaking of your forward proxy which in the case of most data centres and clouds will simply respond with a "Service Unavailable" after 30 seconds. Off course you can defer this to a background job and provide the results elsewhere on your application. But like I said, you would be doing things that the user actually does not need.

3) How would you scale up such an operation heavy application if it were a web app. Have 1000 background jobs running for a 1000 users? An event driven approach will pay off for sure. And 1) illustrates why its easier to do this with a bot.

The real disadvantage I came across was to be able to get it to work with a load balancer. I can write about this if there is more interest.

I almost had a tear in my eye while watching that video. It makes me feel like we're back in the 90s creating IRC bots, but come to think of it, it's a simple and working solution to some problem.

Ah well, I guess there is nothing wrong in getting back to an 'old' yet 'proven' solution.

So is there an easy way to set this up, preferably server-agnostic?

Here is the ruby library that I used https://github.com/ashwinraghav/marvin. It can help you write a pure ruby application that you can later convert to an event-driven app(If you wish)

i feel this is all essentially what message oriented middleware is.

I enjoyed this and quite an inspiring alternative to solving problems.