Question

I have a question on the best way of exposing an asynchronous remote interface.

The conditions are as follows:

• The protocol is asynchronous
• A third party can modify the data at any time
• The command round-trip can be significant
• The model should be well suited for UI interaction
• The protocol supports queries over certain objects, and so must the model

As a means of improving my lacking skills in this area (and brush up my Java in general), I have started a project to create an Eclipse-based front-end for xmms2 (described below).

So, the question is; how should I expose the remote interface as a neat data model (In this case, track management and event handling)?

I welcome anything from generic discussions to pattern name-dropping or concrete examples and patches 🙂

---

My primary goal here is learning about this class of problems in general. If my project can gain from it, fine, but I present it strictly to have something to start a discussion around.

I’ve implemented a protocol abstraction which I call ‘client’ (for legacy reasons) which allows me to access most exposed features using method calls which I am happy with even if it’s far from perfect.

The features provided by the xmms2 daemon are things like track searching, meta-data retrieval and manipulation, change playback state, load playlists and so on and so forth.

I’m in the middle of updating to the latest stable release of xmms2, and I figured I might as well fix some of the glaring weaknesses of my current implementation.

My plan is to build a better abstraction on top of the protocol interface, one that allows a more natural interaction with the daemon. The current ‘model’ implementation is hard to use and is frankly quite ugly (not to mention the UI-code which is truly horrible atm).

Today I have the Tracks interface which I can use to get instances of Track classes based on their id. Searching is performed through the Collections interface (unfortunate namespace clash) which I’d rather move to Tracks, I think.

Any data can be modified by a third party at any time, and this should be properly reflected in the model and change-notifications distributed

These interfaces are exposed when connecting, by returning an object hierarchy that looks like this:

• Connection
  • Playback getPlayback()
    • Play, pause, jump, current track etc
    • Expose playback state changes
  • Tracks getTracks()
    • Track getTrack(id) etc
    • Expose track updates
  • Collections getCollection()
    • Load and manipulate playlists or named collections
    • Query media library
    • Expose collection updates

Answer 1

For the asynchronous bit, I would suggest checking into java.util.concurrent, and especially the Future<T> interface. The future interface is used to represent objects which are not ready yet, but are being created in a separate thread. You say that objects can be modified at any time by a third party, but I would still suggest you use immutable return objects here, and instead have a separate thread/event log you can subscribe to to get noticed when objects expire. I have little programming with UIs, but I believe using Futures for asynchronous calls would let you have a responsive GUI, rather than one that was waiting for a server reply.

For the queries I would suggest using method chaining to build the query object, and each object returned by method chaining should be Iterable. Similar to how Djangos model is. Say you have QuerySet which implements Iterable<Song>. You can then call allSongs() which would return a result iterating over all Songs. Or allSongs().artist('Beatles'), and you would have an iterable over all Betles songs. Or even allSongs().artist('Beatles').years(1965,1967) and so on.

Hope this helps as a starting place.