Purveyor of Iniquities

Audioscrobbler is a web-service of sorts. It keeps track of what you listen to on your computer (iPod support soon? Hope so!) and uses that to figure out what you may like and all sorts of other statistics.

This is basically what I wanted to do a year and a half ago, but I never got around to it well enough. Dave Marmaros wrote a Windows plugin that worked with WinAMP and a quick server (in perl, I think). I wrote an iTunes plugin in AppleScript; actually, it’s the plugin that I’ve been using since then to update my now playing list, which I’m not even going to link to since it’s long enough to crash most browsers or at least give you a lot of time with the beachball, stopwatch, or whatever.

Anyway, it does a lot of what we had planned. One thing they don’t do, though, is aggregate and sell the data, preferably with location tagging. Why? Who knows. I guess they’re not into business models or anything. As is, the service is now donation-ware and apparently nearly swamped w/r/t hardware needs. Since they’ve got the get-up-and-go that I don’t, I gave $20.

One problem that they’ve got a good handle on: resolving song metadata to a canonical list of songs. That was one that stumped us.

One problem that they don’t have a good handle on: how to implement a webservice. For now, it’s a POST with some random variables. Why not do it as XML-RPC and use a super-fast C-implementation of that hooked straight to your database? Makes sense to me, w/r/t speed and scalability. Since the server is just doing inserts, more or less, it could be tuned real well and probably handle forseeable load on one box. Behind that, have a cluster of DB boxes and then a front end webserver or two that do graphs and other webservice stuff.

Instead they’re replacing one convoluted POST-thing with another that would turn the client into a queryable database itself. Why? I have no idea. It looks like they want to have their webservers query the client to answer requests (ie, generate a webpage of the top 50 albums). This doesn’t realy make sense at all, especially when a good number of clients will be offline at any given time. Odder still, the server would poll the clients for updates. Why? It looks like they’re trying to prevent things from getting swamped, but this will just not scale well. Plus, given the firewall situation, it just won’t work a lot of the time.

They seem pragmatic, though, so maybe they’ll come to their senses…

So, anyway, the “Now Playing” list to the right is now powered by Audioscrobbler via RSS 1.0. It took about 30 seconds (literally literally) to rip out the old code and put in the new, which is about a line long and uses Magpie RSS, which works well enough. That’s a good (and trivial) example of why webservices are great and the best way to develop, well, web-based services, especially for those throwing metadata around client-server environments.