It Begins

Summer of Code 2008 officially kicked off on May 26. Within two days, I had about 1500 lines of C written for the result/value split needed for service clients to have a clean API. I started out by writing a patch that was just enough to split xmmsc_result_t into xmmsc_result_t and xmmsc_result_value_t. Then I got the suggestion to create common implementations of all the types used by XMMS2's IPC and encapsulate them in an xmmsc_value_t. That accounted for about 1400 of the 1500 lines of code. :)

As it turned out, all that work wasn't necessary and only the original patch was needed. Fellow XMMS2ers theefer (Sébastien Cevey) and nesciens (Erik Massop) took over from where the patch left off, completely separating the two structures and even converting the CLI code to use the new value_t. So now, service clients will be able to pass arguments and return values around conveniently as xmmsc_value_ts.

Now the big question in my mind is how do I merge this beast? Somehow, I need to get service client code on top of the result/value split code. Do I simply rebase the code and resolve every conflict I can see as I go? Do I squash the service client code down to a few commits? What about authorship in both cases? One thing is certain; it's going to be very hard to visualize everything that needs changing to use the new value_t. But I guess this is just another lesson in how developers do things in the real world and why small, incremental commits are so useful in preventing this situation.

So I suppose there is really only one option: to rebase and pray that it's not impossible to fix. But that's the biggest obstacle in the way of getting service clients into the next release. Anything for the t-shirt!

Service Clients Redux

It's that time again. People are walking around in flip-flops, getting tan(ner), and licking ice cream from cones. It's summer (or it's close enough, anyway), and this summer I'll be getting my tan from the computer monitor and my ice cream from the freezer. It'll be a basement-dweller's summer for me as I'm coding on XMMS2 in this year's Google Summer of Code.

I'll be working on service clients, a continuation of last year's unmerged work. The concept is to provide so-called "service" clients which perform a service (surprise!) that can be re-used by other clients so client authors aren't reinventing wheels all the time. It's just another way XMMS2 eases music player development to the point where making your own interface is a weekend project instead of a thesis project.

What Service Clients Are

The client-server nature of XMMS2 is a constant issue when trying to add new features or fix bugs. What was trivial to accomplish in a monolithic music player is not so trivial in XMMS2, and vice-versa. Service clients are a way to provide the same whipped-cream-and-cherry features you'd find in a monolithic client, but in a reusable, modular, and extensible form. It's cleaner than adding new stuff straight to the daemon, but still fairly simple and straightforward to use.

Service clients work by registering themselves and their callable methods with the XMMS2 daemon. Regular clients (or even service clients, as they're regular clients, too) request a service client from the daemon and call its methods appropriately and get back data. It's that simple. Album art lookup, tag lookup, last.fm submissions, and FreeDB lookup are all easily written as service clients and their functionality is very easily included in any client by use of a few methods. Services are even browseable so, with a little user intervention, a new service client could be used from a client that has no idea how to use the service, at least in theory.

What This SoC Will Bring

Service clients were part of last year's Summer of Code program, completed by student Ning "zeegeek" Shi under the direction of mentor Sébastien "theefer" Cevey. The API works and there are a couple service clients floating around, but zeegeek's codebase was never merged with the main XMMS2 tree. The code needs a full review and some questions about remaining oddities answered. A little bitrot has accumulated since last summer, too. My job will be to clean up the code and get it merged, first.

Later I'll also be writing the first language bindings in Ruby. This, too will be followed by a merge. Too often, Summer of Code projects are completed but remain unmerged for months, creating lots of work later. This summer, I'm including merges as part of the project goals. Once the service client API and Ruby bindings are completed and merged, it's time to take service clients' virginity. It won't be just a framework anymore, but I'll implement some useful clients, starting with a port of xmms2-scrobbler. And of course, this'll be followed by a merge as well.

Then more cool clients will follow. The next generation of collections, (Collections 2.0) also being implemented this summer, will probably implement the collections parser and a more flexible party shuffle as service clients. This is an exciting collaboration opportunity. Other possibilities include a medialib-updater styled service, taglib client, FreeDB/musicbrainz lookup, and album art lookup. I'm outlining way more service clients than I can handle this summer in the hopes that I can pick out an important and doable few and get those few done and merged by the end of SoC. They'll also be indispensable means of clearing up remaining kinks and bugs in the code while establishing some good example code and helping me write documentation.

Working on service clients this summer is exciting and I'm overjoyed that this is my first SoC. This is an excellent project with an excellent team during an excellent summer, so I've little doubt that all this year's projects will be successful. I'm hyped, and you should be, too! Stay tuned for when I finally settle down with a six-pack and start exercising my fingers.