Unofficial Erlang Planet

The new version 3.0 of OneTeam for iPhone has been released, with the push notification feature from Apple Push Notification Service (APNS).

When moving with your iPhone, as a pedestrian, bike rider, car driver or in public transportation, you might have to shutdown the OneTeam for iPhone application while staying connected to your XMPP server. It is convenient for battery saving purposes, or because you want to use another application (iPhone OS 3.0 still does not authorize background applications).

When an event occurs on your XMPP server, it is sent to the APNS (Apple Push Notification Service), which instantly relays it to your iPhone. A push notification is then poped up on your screen, with a sound played. The OneTeam badge (icon) is then changed, showing a new event has arrived, or the number of events waiting for you to read.

You simply have to tap the OneTeam icon to read your new event. The reconnection will be fast and seamless.

This feature is very handy, since you can use your iPhone the way you want (browse the web, use another application) while still being instantly notified as if you were using OneTeam on the background.

This push notification feature is also deployed on OneTeam.im XMPP server, and ejabberd has a component, IMpush, that can send push notifications to the APNS. This makes ejabberd and OneTeam the first XMPP client and server solution that supports the Apple push system.

OneTeam for iPhone has also received fixes and improvements: groupchat, file transfer, image sending... Here are a few screenshots:

An example of Groupchat:

See the Push configuration screen:

And the general OneTeam confguration:

A few comments on the experience after having used OneTeam for iPhone with push and groupchat:

• "Battery life is not impacted by being always connected to my XMPP server on mobile. I have used all mobile XMPP client and this is the first time I can truely stay connected all the time. I feel this is really really the premise of the mobile revolution for mobile instant messaging and mobile XMPP."
• "OneTeam for iPhone client has the type of feature you would expect from a good desktop XMPP client and not a mobile one. You can use groupchat, file transfer. This is really what I need professionally."

OneTeam for iPhone will be available on the Apple's App Store in a few days, after the usual moderation period at Apple.

IMpush is sold as soon as today on the IMstore to prepare ejabberd servers ahead of OneTeam 3.0 with push.

I've used Rats! parser generator heavily on Scala/Erlang plugin for NetBeans, but not write a plugin for Rats! itself.

So I spent my weekend days on a simple Rats! editor module, which implemented syntax highlighting. It's built on Scala.

Here's the snapshot:

It will be available in couple of days.

Motivation

1. The reason for updating an index on every write is the expectation that reads are much more frequent than writes, so that read efficiency is the dominating factor. But if writes are far more frequent than reads, you can use some kind of lazy updating to delay the work until absolutely necessary, and combine the work from multiple updates.
2. An extreme example of a write-dominated, lazily updated database is a full-text inverted index for a search engine. To build one, you might typically read in billions of term-document pairs, sort them by term using some form of external merge sort, and then create a highly optimized index before ever handling a single query.
3. A merge sort can operate continuously, by injecting new records in sorted batches, and then merging the batches as necessary to maintain a set of sorted files with exponentially increasing sizes. And crucially, this kind of incremental merge sort process can allow relatively efficient searches of the data while it's operating, by binary-searching each sorted file. (An example of this is the incremental indexing provided by Lucene.)

User-defined merging

  Merge(Key, EarlierValue, LaterValue)  -> MergedValue

  Merge(K, Merge(K, V1, V2), V3) =:=
  Merge(K, V1, Merge(K, V2, V3))

• If the merge function always returns the later value, then a write replaces any previous value, like an ordinary key-value store.
• If the values are integers, and the merge function returns the sum of the two values, then writing to the table acts like transactionally incrementing a counter.

  merge(_K, N1, N2)
      when is_number(N1), is_number(N2) ->
    {min(N1, N2), max(N1, N2), N1 + N2, 2};
  merge(_K, N1, {Min2, Max2, Sum2, Count2})
      when is_number(N1) ->
    {min(N1, Min2), max(N1, Max2),
     N1 + Sum2, 1 + Count2};
  merge(_K, {Min1, Max1, Sum1, Count1}, N2)
      when is_number(N2) ->
    {min(Min1, N2), max(Max1, N2),
     Sum1 + N2, Count1 + 1};
  merge(_K, {Min1, Max1, Sum1, Count1},
            {Min2, Max2, Sum2, Count2}) ->
    {min(Min1, Min2), max(Max1, Max2),
     Sum1 + Sum2, Count1 + Count2}.

• Always return the earlier value. (What was the first value that occurred for this key?)
• Take the union of two sets. (What are all the values that have occurred for this key?)
• Take the intersection of two sets. (What values have always occurred for this key?)
• Multiply two NxN matrices, e.g., to keep track of a series of rotations applied to a vector in R^N.
• Compose a series of arbitrary operations applied to a space of replaceable objects, e.g.:

  
    merge(_K, _, V) when ?is_value(V) ->
      V;
    merge(_K, V, Op) when ?is_value(V),
                          ?is_operation(Op) ->
      do_operation(Op, V);
    merge(_K, V, Ops) when ?is_value(V),
                           is_list(Ops) ->
      lists:foldl (fun (Op, V) ->
                     do_operation(Op, V)
                   end,
                   V,
                   Ops);
    merge(_K, Op1, Op2) when ?is_operation(Op1),
                             ?is_operation(Op2) ->
      [Op1, Op2];
    merge(_K, Op, Ops) when ?is_operation(Op),
                            is_list(Ops) ->
      [Op | Ops];
    merge(_K, Ops, Op) when is_list(Ops),
                            ?is_operation(Op) ->
      Ops ++ [Op];
    merge(_K, Ops1, Ops2) when is_list(Ops1),
                               is_list(Ops2) ->
      Ops1 ++ Ops2.
  

  The values could be employee records, and the operations could be things like, “change street address to X,” “increase salary by Y%.” Using this pattern, you can get extremely cheap transactional safety for any single-key operation, as long as your merge function implements it.

API

  {ok, Table} = osmos:open(Table, [{directory, D}, {format, F}])

  ok = osmos:write(Table, Key, Value)

  case osmos:read(Table, Key) of
    {ok, Value} -> ...;
    not_found   -> ...
  end

  ok = osmos:close(Table)

• block_size::integer(): block size of the table in bytes, controlling the size of disk reads (which are always whole blocks), and the fanout of the on-disk search trees.
• key_format::#osmos_format{}: on-disk format for keys. (A pair of functions to convert some set of terms to binaries and back.)
• key_less::(KeyA, KeyB) -> bool(): comparison function defining the order of keys in the table. Takes two native-format keys, and returns true if the first argument is less than the second argument.
• value_format::#osmos_format{}: on-disk format for values.
• merge::(Key, EarlierValue, LaterValue) -> MergedValue: the merge function described above.
• short_circuit::(Key, Value) -> bool(): function which allows searches of the table to be terminated early (short-circuited) if it can be determined from a record that any earlier records with the same key are irrelevant.
• delete::(Key, Value) -> bool(): function controlling when records are deleted from the table.

Performance

• 5028735 total records written, for an average of 5587 writes/second (including the time to compute random keys, etc.)
• an average of 109.8 microseconds per write call, which would mean a theoretical maximum write rate of 9111 writes/second (for this table format, machine, etc.)
• the median time per write call was 30 microseconds, and the 90th percentile was 54 microseconds, indicating that the vast majority of writes are extremely quick
• an average of 1900 microseconds (1.9 ms) per read call
• the median time per read call was 979 microseconds, and the 90th percentile was 2567 microseconds

• 17247676 total records written, for an average of 2396 writes/second
• an average of 329.7 microseconds per write call, for a theoretical maximum write rate of 3033 writes/second
• the median time per write call was 39 microseconds, and the 90th percentile was 88 microseconds
• an average of 13076 microseconds (13 ms) per read call
• the median time per read call was 6081 microseconds, and the 90th percentile was 34094 microseconds

Welcome to the start of the erlang:lists series where we list some interesting happenings in the world of Erlang.

erlang:lists(CouchDBNaked) - Harish Mallipeddi, a performance engineer at Yahoo, has put together a great post on the internals of CouchDB, and how to even use some of the couch source to build your own B-Tree based mini-application.

erlang:lists(ErlangFactory) - Slides and videos are up from the 2009 London Erlang Factory conference. About half have videos and most have slides available. Not sure yet if they will all have videos or if there are reasons for not showing the films for some speakers.

Each week I’ll mention a few must-see articles, blog entries or videos. If you have something to bring to my attention - contact me at chad at inakanetworks com.

The first presentation by me (Mickaël Rémond) was titled "OneTeam Media Server: Adding Video to Instant Messaging with Erlang".

The second presentation by Geoff Cant was title "Whitelabel Erlang" and give feedback on how Erlang can be used to write scalable hosted application for business.

RabbitHub is our implementation of PubSubHubBub, a straightforward pubsub layer on top of plain old HTTP POST — pubsub over Webhooks. It’s not well documented yet (understatement), but that will change.

It gives every AMQP exchange and queue hosted by a RabbitMQ broker a couple of URLs: one to use for delivering messages to the exchange or queue, and one to use to subscribe to messages forwarded on by the exchange or queue. You subscribe with a callback URL, so when messages arrive, RabbitHub POSTs them on to your callback. For example,

• http://dev.rabbitmq.com/rabbithub/endpoint/x/amq.direct is the URL for delivering messages to the “amq.direct” exchange on our public test instance of RabbitMQ, and

• http://dev.rabbitmq.com/rabbithub/subscribe/q/some_queue_name is the URL for subscribing to messages from the (hypothetical) queue “some_queue_name” on the broker.

(The symmetrical …/subscribe/x/… and …/endpoint/q/… also exist.)

The PubSubHubBub protocol specifies some RESTful(ish) operations for establishing subscriptions between message sources (a.k.a “topics”) and message sinks. RabbitHub implements these operations as well as a few more for RESTfully creating and deleting exchanges and queues.

Combining RabbitHub with the AMQP protocol implemented by RabbitMQ itself and with the other adapters and gateways that form part of the RabbitMQ universe lets you send messages across different kinds of message networks — for example, our public RabbitMQ instance, dev.rabbitmq.com, has RabbitHub running as well as the standard AMQP adapter, the rabbitmq-xmpp plugin, and a bunch of our other experimental stuff, so you can do things like this:

• become XMPP friends with pshb@dev.rabbitmq.com (the XMPP adapter gives each exchange a JID of its own)

• use PubSubHubBub to subscribe the sink http://dev.rabbitmq.com/rabbithub/endpoint/x/pshb to some PubSubHubBub source — perhaps one on the public Google PSHB instance. (Note how the given URL ends in “x/pshb”, meaning the “pshb” exchange — which lines up with the JID we just became XMPP friends with.)

• wait for changes to be signalled by Google’s PSHB hub to RabbitHub

• when they are, you get an XMPP IM from pshb@dev.rabbitmq.com with the Atom XML that the hub sent out as the body

RabbitHub is content-agnostic — you don’t have to send Atom around — so the fact that Atom appears is an artifact of what Google’s public PSHB instance is mailing out, rather than anything intrinsic in pubsub-over-webhooks.

We’ve also been experimenting with using http://www.reversehttp.net/ to run a PubSubHubBub endpoint in a webpage — see for instance http://www.reversehttp.net/demos/endpoint.html and its associated Javascript for a simple prototype of the idea. I’m playing with building a simple PSHB hub in Javascript using the same tools.

This is more verbose answer to @bubbafat twitt-question. It started lkie this:

1. 1. you can load the precompiled module at later time from a path not being provided to compiler.
   2. you can use M:F(Args) function invocation in #erlang, any of M, F, Args being variables dynamically referencing module, function and argument list.
   3. you can construct erlang AST tree programmaticaly, compile it at runtime and load the resulting beam.
   4. you can acheive the p.3 result using a helper tools such as LFE, Smerl or  “Dynamic” module generation with compile-time macros
   5. … and I’m sure there is more

What is fast becoming a regular fixture in my diary is my entry with a few friends into the ICFP Programming Contest each year. This is a three day programming competition in which you can write in any language to solve the problems given. The competition is still in progress, though my team’s decided to stop — we’ve had enough fun for one year, and there’s only so far you can go with very little sleep and shockingly poor maths — but we’ve done much better than last year, learning from our previous mistakes…

Last year, the competition was to write a controller for a Martian Robot. You were given the simulator and the scenario files for it and had to write a controller to direct it to avoid boulders, rocks, and 7-fingered martians. Control was a little tricky, our path finding frequently never terminated fast enough and we never actually figured out how hard it was to direct the Robot until about an hour before the finish — and yes, we went the whole 72 hour distance then. We were totally wiped out, realised we’d solved the wrong question, or at least not spotted where the difficulty lay until it was far far too late and ended up doing very badly — somewhere below 250th position. In the course of the three days we wrote about 9000 lines of Haskell and almost every commit comment was either a single letter or a curse of some sort. A friend of ours wrote a very simple controller (in C++) and did very much better than us.

We learnt several things from that experience. One was to really think about the problem and work out where the difficulties lie before getting bogged down in a broken implementation. The other was the value of writing tools — namely visualisers so that you could see what’s going on. A picture really does paint a thousand words, and Haskell has some nice GTK+/Cairo bindings so it’s pretty easy to knock out a good visualiser. Last year, because communication with the simulator was via network sockets, we also used this to dump out data to be visualised. We had to run the simulator in real time (though some teams did work out how to hack it so it would run much much faster) and so it made sense to run the visualiser in real time too — it was pretty cool to watch what our rover was doing and we also dumped out our graph for route finding which we overlaid too. However, because it was so timing sensitive, we found that our rover behaved differently if it was running with the visualiser or not — the extra cost of dumping out debug information altered its behaviour!

This year, the task involved moving satellites between different orbits. We were given only the compiled scenarios, and a spec of the VM which they were to run on. So step one was implementing the VM. This was pretty straight forward, though we immediately spotted we want this to run as fast as possible because a valid solution could be up to 3,000,000 “seconds” long and there’s no way we’re sitting around for that! — 3,000,000 seconds is 833 hours which is about 11.5 times longer than the whole competition was due to last! So I pretty much treated Haskell as C, got out the bit masks, and had the whole thing running in my CPU cache (ok, I have a 12MB L3 cache, so it’s not as impressive as it sounds!). I was quite pleased — with a bit of maths I worked out I was spending about 250 CPU cycles per VM instruction — about 8 million instructions per second. We were getting through the 3,000,000 “seconds” in under 2 minutes and this was clearly very usable. We were also dumping out to a file all sorts of debug information which we would later parse and build a visualiser for. Sadly, that same friend I mentioned earlier also wrote a VM in C++ and got to about 35 CPU cycles per VM instruction. Still, within a factor of 10 is quite good for Haskell — both of us used pretty much every trick we knew to make it go fast. I guess there’s still work to be done for the GHC developers!

Next task was writing the visualiser. Again, Haskell, GTK+/Cairo, a nice slider to allow us to step through each frame, plotting the output, and a textual dump of the information we capture in each frame. Also, quick navigation to the next “interesting” event — eg when we fire thrusters — searching for events like these amongst 3 million frames is a little frustrating, so quickly being able to jump computationally was a good extra feature. It suddenly became very cool to rapidly step through every 100 frames and get a primitive video of our satellite moving about, and gravity playing havoc with its every move!

And now to the problem itself. There’s a thing called a Hohmann Transfer which allows you to change between different orbits using two burns. You use one burn to push you out of your current orbit and to go into an elliptical orbit, and then 180° later you do another burn which puts you back into your target circular orbit. Task one was simply doing this maths, getting it right, and going from one circular orbit to another. Sometimes the orbit would be further out, sometimes further in. This was reasonably straight forward.

The second task was not only changing orbits, but also meeting up with another satellite in the target orbit. You had to stay within 1km of the target satellite for 900 seconds to pass. So, between two steps, you could use your position and your target’s position to calculate enough information to solve the necessary equations. You would know how long you needed to sleep for (i.e. carry on in the current orbit), how much you needed to burn, how long the transfer between orbits would take, and what the final burn would be.

In this task, there were four scenarios. Three of them we got quite quickly, but the fourth eluded us for a long time (in fact, although we got a solution, we don’t have a single piece of code that can do all four tasks, so it doesn’t really count). The problem with the fourth scenario is that the target satellite is a VERY long way out. Our equations are for continuous maths, but the simulator is discrete. So when we calculate exactly how long to sleep for (which is the number of VM steps, or “seconds” to sleep for), that value has a fraction, but you can’t sleep for fractions. So this means that you either burn a bit early, or a bit late, or you try to spread the burn over two steps. Either way, you burn at the wrong time, and so you arrive in the wrong place (exactly the same rounding issue happens with the transfer time (i.e. the amount of time to spend in the elliptical orbit), and so you either try to come out of the elliptical orbit early or late). For close to earth, as three of the four problems were, this inaccuracy doesn’t matter too much — the perimeter of the circles you’re landing on is small enough that if you’re out by a few fractions of degrees, you’re still in real terms close enough to the target satellite to be within 1km and score points. When you’re going a long way from the earth, these few fractions of degrees correspond to a long distance — the closest I could reliably get was just under 10km away from the target. Not good enough.

We tried going too far out and ahead of the target, and then trying again in the hope that it’d be easier to be more accurate if we were closer to the target to start with. We tried going just not far enough and behind the target and trying again, all to no avail. The problem there is that when you’re a long way out, each step of the simulator counts for several thousand miles, and if your window of when you need to fire your thruster to hit the target is quite small, you can frequently miss it between two steps. We actually discovered that it was much much better to try going out, if you miss it, come all the way back in to, say an orbit of 1.025 * EarthRadius and then going back out — this was faster and gave us many more attempts, and as we were orbiting the Earth so quickly, we could afford to wait until the stars were in alignment, a particular simulator step showed us that we were really really close to the ideal time to fire, and to try again. Sadly, again due to the differences between the continuous maths we were doing and the discrete maths of the simulator, after a few outs and ins, we noticed we were very much not in a circular orbit around Earth when we thought we were. Rounding errors had rather crept up on us.

So that is where we got stuck. We spent many hours arguing about maths and angles. About the only maths we didn’t argue about was vectors, but then we’d previously (re-)written (several dozen) vector maths libraries as a result of games we’ve written (or attempted) so those libraries are reasonably solid. The visualiser worked really really well — our friend with the uber-fast C++ VM didn’t have one, and it showed, when he was staring at columns of numbers not understanding what his satellite was doing. Really, we needed to throw all our maths away, and implement an iterative solver — effectively cloning the maths the simulator was doing. Only this way could we be accurate enough. But neither of us have maths strong enough to solve those equations, or at least enough clue to work out where to start. Nevertheless, at one point, we were in 52nd position, which is a stunning improvement from last year, though we have dropped back a bit now as other teams are still working on it. It finishes at 7pm BST today, though we’re not going to do any further work on it.

For those interested, the 3rd part of the question was the same as the 2nd part — i.e. meet up with a different satellite, except that now the target satellite can be in an elliptical orbit, and you can start in an elliptical orbit too. The fourth part was to add in an element of AI so that you can visit several randomly positioned satellites, stopping at a special refueling satellite if necessary to refill, and doing it as fast as possible. Oh yes, and the Moon makes an appearance in the fourth part, adding much more fun to your equations (figure-of-eight orbits around the Earth and Moon anyone?!).

We took it at a much more relaxed pace this year, I even had to go out to play in a concert at one point, though it was mercifully brief, but had more fun than last year, did better, and didn’t make anywhere near as spectacular mistakes!

Yesterday I did a StackOverflow podcast with Joel Spolsky and Jeff Atwood. We talked about CouchDB and Erlang, among other things: StackOverflow Episode 59

I'm pleased to announce Erlang plugin (ErlyBird) version 1 for NetBeans 6.7 is released.

NetBeans 6.7 RC3 or above is a requirement.

What's new:

• It's rewritten in Scala instead of Java
• More reliable instant rename
• Display extracted document information from source comment when doing auto-completion.

To download, please go to: https://sourceforge.net/project/showfiles.php?group_id=192439&package_id=226387

To install:

• Open NetBeans, go to "Tools" -> "Plugins", click on "Downloaded" tab title, click on "Add Plugins..." button, choose the directory where the Erlang plugin are unzipped, select all listed *.nbm files, following the instructions.
• Make sure your Erlang bin path is under OS environment PATH, you can also check/set your OTP path: From [Tools]->[Erlang Platform], fill in the full path of your 'erl.exe' or 'erl' file in "Interpreter", for instance: "C:/erl/bin/erl.exe". Or open the "Brows" dialog to locate the erlang installation.
• When you open/create an Erlang project first time, the OTP libs will be indexed. Take a coffee and wait, the indexing time varies from 10 to 30 minutes depending on your computer.

I’ve been living in linked-in driver land for the past few weeks. I guess that’s what I get for publishing basic_erl_driver. It’s been interesting work so I certainly haven’t minded doing it.

Well, I didn’t mind it until I had to build one of my drivers on Windows. It’s been a long time since I’ve done much Win32 development but I used to know my way around Visual C++ pretty well. “I used to do this shit for a living. How hard could this be?”, I thought to myself.

Three words: famous last words.

Three more words: C++, linker, XML.

Two final words: sheer frustration.

After wrestling with Visual Studio Express C++ Edition 9.0 (or whatever crazy name MS uses) for a day and a half I finally have a working driver. Here’s the nuggets o’ knowledge I learned along the way. These notes assume you’re porting a working driver from OS X/Linux/BSD to Windows although most of them are applicable if you’re starting from scratch on Windows, too. They also assume you’re building code from inside of Visual Studio because, frankly, I don’t care enough about Windows to figure out nmake, too.

• Start with a blank Win32 DLL project. Don’t let Visual Studio create stdafx and friends. Down that path lies madness. You’re much better off to create a blank project and import your code.
• Add the erts-<version_number>/include directory to your project’s include path. You’ll need this so the compiler can resolve erl_driver.h.
• Don’t forget to include string.h before erl_driver.h. erl_driver.h uses memcpy() without including string.h. Including string.h first will fix a compiler warning and a possible runtime crash.
• Very Important: Right-click your project and navigate to the Linker -> Manifest File option. Enter this magical text into the Additional Manifest Dependencies field:

  type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processArchitecture='x86' publicKeyToken='1fc8b3b9a1e183b'
  

  I believe this tells the compiler to link the DLL with the Visual C++ 9.0 runtime. This is the equivalent of the C stdlib on other platforms, I think. Erlang will be unable to load your driver if you skip this step.

---

Observation: Who in their right fucking mind thought it was a good idea to add XML descriptors to the link step of building a C library?! I take back every bad thing I’ve ever said about Java’s use of XML. SOAP, with all of its angle brackety warts, almost looks sane in comparison.

There are probably better ways to accomplish the same goal given my dated platform knowledge. If you know of a better way to do this, please drop a comment and set me straight!

One of the drivers I’ve been working on is to allow SpiderMonkey to interface with Erlang. I’ve asked and am waiting for permission from my client to open source the code since I think it’d be generally useful. If that doesn’t pan out I’m strongly considering doing another driver — open source from the beginning — to interface with V8 or possibly WebKit’s engine. I’ve got some ideas on how JSON could smooth the interop between the two languages. Anyone up for either working on or sponsoring work on this?

Paul has blogged about overcoming mnesia performance issues in the past, but I don't think we've talked much about the ultimate strategy -- keeping data out of mnesia altogether.

When we first started serving ads, we stored information about every single ad impression in a huge mnesia database, for retrieval on click, and for building behavioral profiles. Almost needless to say, this didn't scale very far. We spent many a day last summer delving into mnesia internals, fixing corrupted table fragments after node crashes, bemoaning how long it took new nodes to join the schema under heavy load, and so on.

One of the simplest and most effective changes that got us out of this mess was not to store any per-impression data in mnesia at all -- instead, we started logging the data to flat files on disk, and storing a small pointer to the data in a cookie so we could read it back the next time we saw the user. Hardly a revolutionary solution . . . it's well-known that disk seeking is the enemy of performance. The hardest part was coming to realizations like, "Hmm, I guess we don't really care if a node goes down and we lose part of that data!"

We've open-sourced one of the main components that enabled this strategy: flatula, an Erlang application that manages write-once "tables" that are really just collections of flat files. It looks a bit like dets, except that it doesn't support deletions, updates, or iteration, and you can't make up the keys. But when you don't need those things, it's hard to imagine a more efficient way to store data.

If you'd like to learn more, there's a brief tutorial on the Google Code site.

Recently I was looking for an example on how to do redirect in webmachine. Unfortunately I haven’t found one. So I started figuring it out by myself. After try and error using brilliant wmtrace_resource It turned out to be trivial ;). Here is the example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

%% @doc Example of redirect webmachine_resource.
 
-module(redirect_resource).
-export([init/1, resource_exists/2, moved_temporarily/2, previously_existed/2]).
 
-include_lib("webmachine/include/webmachine.hrl").
 
init([]) -> {ok, undefined}.
 
moved_temporarily(ReqData, Context) ->
  Site = wrq:path_info(site, ReqData),
  Location = base64:decode(Site),
  {{true, Location}, ReqData, Context}.
 
previously_existed(ReqData, Context) -> {true, ReqData, Context}.
 
resource_exists(ReqData, Context) -> {false, ReqData, Context}.

The resource is mapped in my dispatch.conf as
{["redirect", site], redirect_resource, []}.
You can do a request like http://host.com/redirect/aHR0cDovL2xhbWJkZXIuY29t
The redirect_resource will interpret the last token in the path as base64 encoded location to redirect to.