Note that there are some explanatory texts on larger screens.

plurals
  1. POExposing a remote interface or object model
    text
    copied!<p>I have a question on the best way of exposing an asynchronous remote interface.</p> <p>The conditions are as follows:</p> <ul> <li>The protocol is asynchronous</li> <li>A third party can modify the data at any time</li> <li>The command round-trip can be significant</li> <li>The model should be well suited for UI interaction</li> <li>The protocol supports queries over certain objects, and so must the model</li> </ul> <p>As a means of improving my lacking skills in this area (and brush up my Java in general), I have started a <a href="http://Telharmonium.devjavu.com/" rel="nofollow noreferrer">project</a> to create an Eclipse-based front-end for <a href="http://xmms2.xmms.se" rel="nofollow noreferrer">xmms2</a> (described below).</p> <p>So, the question is; how should I expose the remote interface as a neat data model (In this case, track management and event handling)?</p> <p>I welcome anything from generic discussions to pattern name-dropping or concrete examples and patches :)</p> <hr> <p>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.</p> <p>I've implemented a protocol abstraction which I call <a href="http://telharmonium.devjavu.com/browser/trunk/xmms2-client" rel="nofollow noreferrer">'client'</a> (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.</p> <p>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.</p> <p>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.</p> <p>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 <a href="http://telharmonium.devjavu.com/browser/trunk/xmms2-model" rel="nofollow noreferrer">'model'</a> implementation is hard to use and is frankly quite ugly (not to mention the UI-code which is truly horrible atm).</p> <p>Today I have the <a href="http://telharmonium.devjavu.com/browser/trunk/xmms2-model/src/se/fnord/xmms2/model/Tracks.java" rel="nofollow noreferrer">Tracks</a> interface which I can use to get instances of <a href="http://telharmonium.devjavu.com/browser/trunk/xmms2-model/src/se/fnord/xmms2/model/Track.java" rel="nofollow noreferrer">Track</a> classes based on their id. Searching is performed through the <a href="http://telharmonium.devjavu.com/browser/trunk/xmms2-model/src/se/fnord/xmms2/model/Collections.java" rel="nofollow noreferrer">Collections</a> interface (unfortunate namespace clash) which I'd rather move to Tracks, I think.</p> <p>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</p> <p>These interfaces are exposed when connecting, by returning an object hierarchy that looks like this:</p> <ul> <li>Connection <ul> <li>Playback getPlayback() <ul> <li>Play, pause, jump, current track etc</li> <li>Expose playback state changes</li> </ul></li> <li>Tracks getTracks() <ul> <li>Track getTrack(id) etc</li> <li>Expose track updates</li> </ul></li> <li>Collections getCollection() <ul> <li>Load and manipulate playlists or named collections</li> <li>Query media library</li> <li>Expose collection updates</li> </ul></li> </ul></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload