API bindings in Erlang

15 Oct 2010

Erlang  Technology 

Originally posted at

About 6 months ago, I started to teach myself Erlang. I’ve always found it difficult to learn a new language without a decent test project to try out things with, and so I decided to add scrobbling support to our jukebox. I got pretty far, but then I got buried in other projects, and didn’t have time to work on it. However, I’ve now finally managed to get around to finishing it off and it’s now running happily, so now’s a good time to write about the things I found along the way.

I started off with the XML-RPC interface, but it turned out the standard Erlang XML-RPC library wouldn’t play nice with In fact, the Erlang XML-RPC library has it’s own kludgy internal HTTP implementation, which is never a helpful thing, especially when it only supports HTTP 1.1 and spits out HTTP 1.0… I started rewriting it with the proper HTTP library, but given parts of it’s interface expect being able to be handed an arbitrary socket and do things on that, it was going to require breaking the API, and so I decided to do the sensible thing and switch to using the REST interface instead.

Everything starts going a bit smoother after this. As it turns out once I start implementing the various functions, there’s a lot of common code, and it turns out I can get the call-specific code down to very little. See for example the below code for Album, Artist and Title searches – the 3 last arguments to each define which XML structures to look inside, which to remember for part of the return values before looking inside, and which are pure text nodes.

I then realised I was missing one big element: the actual scrobbling of songs. Turns out that this part of the API is done in an entirely different way to everything else, which is not helpful. acknowledge this and are apparently working on a v2.0 that’ll fix this, but for the here and now, I had to build something else. Scrobbling is still a REST interface, but everything else is different to the rest of the API – plain text v.s. XML, and a different 2-stage authentication mechanism v.s. the 1-stage of the main API. I’m guessing that this separation is probably for historical reasons from when merged with the Audioscrobbler project.

Luckily, I’d already written a bunch of REST-submission boilerplate as part of the other API work, and parsing the output of the scrobbling interface wasn’t too awful either given Erlang’s built-in pattern matching. As this was the main part of the API actually needed for the jukebox now done, I pretty much stopped at this point, and it’ll need expanding if someone wants full support for all features at a later date, but the core has enough features already to make this probably minimally painful.

There’s a few other things that I needed to add – mainly a user-specific settings file needed to store the username/password (and the API key/secret as this is an opensource project and I don’t want to give my key away), and some work to tie this into the actual music playing – but that’s all now done, and we have a working, scrobbling jukebox!

Previously: Android Postcode app Next: Map overlays (or how to break Google Maps)