Last week I began discussing a tool I will be making available for free: The Gibbs Universal Industries Sentimeter. The Sentimeter provides real-time sentiment analysis, that is, a measure of the positive or negative feelings related to a given search term on Twitter.

Underlying the tool is the Twitter Search API, which is used to retrieve the tweets containing the search term, and the OpenAmplify API, which provides a linguistic analysis of either a block of text or the contents of a URL.

When I hit on the idea of the Sentimeter my first thought was to implement it using one of my favorite tools: SAP's Xcelsius, a business intelligence dashboard creation system that I first reviewed in 2004 and have mentioned numerous times since.

I have also castigated SAP in a Backspin column for the company's atrocious product management where Xcelsius is concerned. While SAP has fixed some of the more egregious problems, it apparently still can't be bothered to respond to questions about other serious issues. For example, I have had a question in the forums from early June that apparently isn't worthy enough for SAP product management to address. Very sad.

Anyway, my first step in creating an Xcelsius dashboard was to get around a security issue: Xcelsius, being based on Adobe Flash, is constrained by Flash's security sandbox architecture.

Starting with Flash 7, a request to access a URL outside the exact domain that a Flash movie was loaded from would fail to prevent cross-site scripting exploits. With the release of Flash 9 this security architecture was further tightened and the result is that getting a Flash movie to access two different domains is tricky.

The answer? Use a proxy. By using an HTTP proxy, all requests, including the one to load the Xcelsius dashboard, are made to the same domain (that is, the domain of the proxy), which the proxy routes to the target domains transparently.

Ryan Goodman, Xcelsius guru extraordinaire and purveyor of fine Xcelsius components, tackled this problem some time ago. He recently sent me a really simple proxy using cURL wrapped in PHP to try. This is great unless your hosting provider, like mine (EasyCGI), doesn't provide cURL.

This lead me down a very dark path. First I researched proxies written in PHP, Perl and Python, but they either required language modules that weren't available on EasyCGI or, for various reasons, handled the proxy request incorrectly. For example, the Twitter API request embedded in the OpenAmplify request has to be URL encoded, but most proxies take that URL encoding and re-encode it with predictably annoying non-results.