When developing Riker, I had a bit of a choice – I could either write (from scratch) a new library to interface with the MusicBrainz XML webservice, or I could create bindings to access the existing libmusicbrainz library from within Vala. Up to today, I’ve gone a little ways down both paths, and both have problems.
If I write new bindings from scratch, they’ll have some nice features like integrating into the Glib main loop, and automatically determining proxy settings from the environment. But it will be a lot of coding; and even more debugging.
The existing libmusicbrainz code is better tested, and writing bindings is less overall code to write. Unfortunately, I’m writing Vala bindings for the C bindings to a C++ library. The extra steps cause some weirdness, which means that the bindings are more complicated than I would like.
And then there are a few things with the C bindings to libmusicbrainz that it simply gets wrong. For example, it has no working typechecking! As a result, even some of the internal test code gets types mixed up, causing hard to debug issues. I’m working on a patch to correct this, which will change the C bindings API slightly. (But curiously enough, not the ABI).
But in the end, simply to get started faster, I decided that the bindings are the way to go. The hypothetical GObject-based MusicBrainz webservice library will have to wait for another day.
Take a look at my progress so far on the vala bindings at libmusicbrainz4.vapi.
Leave a Reply