Today as part of a new service that we’re going to make use of at work, I was tasked with exploring what it would take to make outbound phone calls to users.
In the distant past I had a trixbox in my house, but after a failed yum upgrade and subsequent axing of my landline to go all cell, I’ve since removed the trixbox. Well some things never quite die I guess as here I am standing back up trixbox to do a P.O.C. outbound call thing-a-ma-jig.
The basic premise is simple; call a user and tell them their password has been changed. But it would be laughable to call the implementation simple. There is nothing simple about telephony. It’s another one of those “things”, like email and time, that just seems to be too complex for what it’s trying to do.
So to make a long story short, the P.O.C. works and if I had to explain it to you, I could. But it’s so massively unmaintainable, prone to errors, and in general just a major clusterfuck, that I’ve recommended against running it.
Here’s how it works
In other news, I’ve added two new things to savory.
- An APC Cache Information report
- A REST API
The cache report was created out of a need to see “what’s happening to the APC cache” in savory. Recently there were some perceived performance problems with savory. So, to start alleviating said problems I started optimizing where I could. First was adding an APC cache so that the whole PHP kit-n-kaboodle did not need to re-compiled every time a page was accessed.
This worked well, but there’s no good way to see “what’s happening” without using the apc.php file that is included with APC. What I don’t like about said file is that it doesn’t participate in savory’s permissions system. It is, however, a good candidate for a report. So I ported it. The end result, is this.
<img class=”size-medium wp-image-956 aligncenter” title=”savory-apc-cache-report” src=”http://caphrim.net/tim/wp-content/uploads/2011/03/savory-apc-cache-report-234x300.png” alt=”” width=”234” height=”300” /></a></p></p>
If it looks like the output of apc.php that’s because it is. It’s just been worked into a savory report. This allows us to remove the apc.php file completely. Hooray.
The other feature that was added is a REST API. Why?
Well, this stems from a snafu I encountered when investigating caching. With the XML-RPC API, all the URLs are the same because the differentiating portions are in the payload of the request…not the URL.
So when a caching server, like squid, sees the same URL, it serves the response. But if you request a URL ID for google.com and one for yahoo.com, unless the API URL is different, a caching server may return the incorrect response. It’s detailed more in the caching wiki entry [available here](http://caphrim.net/dokuwiki/doku.php?id=savory:1.1:manuals:developer:api:xmlrpc:notes:limitations
So savory now has a semi-REST API available to it. It’s not pure REST, in the sense that it doesn’t use all the HTTP verbs, but this is intentional because there is crappy support in most scripting language libraries for anything aside from straight-up GET and POST.