So XMMS2 is participating in the Summer of Code again! This year we have a lot of really cool project ideas. I'm especially excited about Service Clients, Visualisation, and any potential client development.

This year instead of participating as a student I will hopefully be mentoring a/some really cool project(s). I've been helping students out in our SoC specific channel: irc.freenode.net #xmms2-soc with trying to get their proposals in order as well as their conceptions about just how XMMS2 works. In particular a lot of them seem to be confused by our IPC mechanism. The fact that it isn't just plain text and that it supports some nice data types has certainly been surprising or confusing for some. So, xmmsipc is a binary IPC protocol that supports serialization of: arrays, dictionaries, dictionaries with source data (propdicts), unicode strings, bytestreams, (u)ints, floats, and even the collections structure (xmms_coll_t). This makes possible some really powerful communication between clients and xmms2d.

Beyond simply support support for some nice datatypes we also get by a combination of xmms2d, xmmsipc, and xmmsclient we get further cool features. Communication between clients and xmms2d isn't simply limited to one time request-response operations. We include two ways to get updated data. The first is broadcasts. In xmmsclient we provide a way to attach notifiers to ipc calls, so that when the response arrives a callback will be notified. This is the most common way to use xmmsclient. Broadcasts are ipc methods that you request once and get notified every time they occur. These are usually used for small pieces of data (often integers) like the currently playing song id, or the playback status. Each time one of these things change if the user has requested to receive the broadcast they get it. Sometimes when there is a lot more data, it comes a lot more often, or the client is more likely to disconnect it we use the second option: signals. Signals are like broadcasts except the decision to receive the data again has to be made every time, by restarting'' it. This is usually achieved by calling xmmsc_result_restart on the result object.

XMMS2's asynchronous design leads to a need for xmmsc_result_t, or our result object. Result objects are returned immediately by any request that has to communicate with the server via IPC, at which point the user typically has two options: wait'' for the response, or set a notifier on the result. Waiting on the result is often used in simple clients, it blocks the client until the result comes, so is not really suitable for a GUI client. To facilitate this synchronous process XMMS2 provides a xmmsc_result_wait function, which sets up a mini-event loop which waits for the IPC event until it arrives. After this the client can pull out the data they want from the result object. The other option which is much better for GUI clients is to make use of our notifier system. For this to work something has to be setup to monitor the file descriptors used by the ipc protocol to read and write data between the client and xmms2d. Once xmmsclient is attached into some kind of event loop like that we provide methods which can read from the file descriptor when there is data to read, and write out when there is data to write. So a notifier is called when the data to read reflects the method to which the notifier was attached. That way a separate function can be made to handle the data that has just arrived from the server.

So, hopefully this clarifies for students just how clients communicate via IPC and some of the capabilities and functionality provided by our IPC system when used by xmmsclient.