Now that I'm settled back in beautiful Kirksville, I've started working full steam on my Google Summer of Code project, which is to add iTunes music sharing to Amarok (also known as "DAAP support"). Currently the only maintained DAAP library is part of the Banshee project, so its in C#. Libopendaap and kio_daap (which has a fork/branch of libopendaap) hasn't been touched in a year and doesn't work for me, I think due to 64-bit issues (which I tried to diagnose, but it was entirely mysterious to me). Rhythmbox has its own implementation of DAAP, written as a SOC project last year and uses glib, so it quickly scared me a way.
So at the risk of being accused of "not written here", I've decided to write my own DAAP implementation, at least for the client-side (I'm still holding out hope for mt-daapd integration). I could make it a separate library for use by other KDE applications (Juk?); I will at least not couple it with Amarok to leave that option open (though I might go ahead and use metabundle...).
To become familiar with the protocol, I've written a Ruby script (it doesn't do anything yet, but its on
SVN). I think it will be possible to actually turn it into an Amarok script to provide bare-bones basic DAAP client support - basically the user would type in the IP address and all the tracks would be loaded into the playlist.
Currently it gets a 'stack level too deep' error when trying to get a database listing, which I blame on learning LISP last semester. It uses the same sort of recursive algorithm we used in class all the time. It shouldn't be too difficult to rewrite it iteratively.
One "interesting" feature of the iTunes implementation of DAAP is that it requires an almost DRM-like messed up MD5 hash, meant to reduce interoperability of iTunes with others. Luckily David Hammerton of libopendaap has already
figured it out. If you have a spare minute you might check out that code, its pretty hilarious. I've never liked Apple, now I have a reason not to. (This means my Ruby prototype won't ever work with iTunes).
A thanks also goes to James Willcox (snorp) of the Banshee project for pointing this out and providing other useful pointers. I consider Banshee to be Amarok's most significant competitor in the open source world, but I think we all recognize that our real competition isn't open source.
On a similar note, I contacted Cole, a fellow SOCer who is implementing
DAAP for XMMS2. He also determined that none of the current DAAP implementations are satisfactory and is implementing his own library as well. Though our conflicting library requirements mean we can't directly colloborate, I think we will be comparing notes as the summer continues.