Tourniquet

Stop the Bleeding!

Project Description
Tourniquet is a personal caching proxy for Twitter. Client applications access Tourniquet in the same way that the Twitter API itself would be accessed by the application. Tourniquet caches the data received from Twitter in its own persistance layer, and is able to serve up cached data when the live API is down. This same thought process is also applied to outbound tweets and direct messages: Tourniquet will store the message and forward it to Twitter when the API is available. Because Tourniquet is a personally-hosted solution, there are no Twitter-imposed API hourly usage limits for accessing cached data.

Status
Tourniquet is in its first release development cycle, which is largely a prototype/proof of concept. Features and interfaces are subject to change as code is written, tested, and refactored.

Requirements
This iteration of Tourniquet is an ASP.NET 2.0 web application, and must be hosted on a web server. It uses its own built-in HTTP Basic Authentication mechanism, so the web server must grant ONLY anonymous access to the web application. For example, in the IIS properties for the application, uncheck Basic, Digest, and Integrated Security or else the custom authentication will not work (i.e., IIS will try to authenticate the supplied credentials using OS-level security before Tourniquet gets control of the page lifecycle).

To use the URL Rewriting functionality, ASP.NET must be mapped to handle .xml files (and optionally to .json, .rss, and .atom as well, if you want to pass requests in these formats through Tourniquet, though they will not be parsed or cached).

Tourniquet implements its persistance layer using a Provider model so that any type of back-end data store can eventually be used. The only provider that is currently available is one based on ADO.NET and SQL Server. As such, access to a SQL Server database is required. A SQL Server 2005 Express database is included.

Considerations for Using Tourniquet with Twitter Client Applications
List of Twitter clients known to work with Tourniquet

Tourniquet's primary design goal was to allow existing Twitter clients to access the Tourniquet application as if it were Twitter's actual server. The mechanism that Tourniquet uses to provide this pass-through functionality is URL Rewriting (using UrlRewriter.NET). This works by ASP.NET intercepting the web request for an .xml file and changing the URL to ~/proxy.aspx?command=... instead.

The caveat here is that the Twitter client application must allow the user to configure the Twitter server address that is used by the application (so instead of http://twitter.com/, the user must be able to specify something like http://theirdomain.com/tourniquet/).

When the user sends a tweet or direct message, Tourniquet will perform a store-and-forward operation. This is useful because messages will not get lost if the Twitter API is unavailable (Tourniquet will just hold on to it until the server is back up, and then will send the message at that time). One thing to be aware of is that a "fake status" will be returned by Tourniquet to indicate that the "store" operation was successful. This is nearly equivalent to the actual status that Twitter would have returned, except that the status's ID will be set to -1 and the source will say "QUEUED (NOT LIVE YET)". The actual status will appear in the timeline after the "forward" operation takes place.

Roadmap

Administration

Authentication