XIRUSS-T Update: Client Starting To Take Shape

In the unlikely event that there's somebody out there waiting breathlessly for me to continue my exploration of versioned hyperdocument management, I wanted to report on why I haven't posted in the last couple of days.

I've been working full out on implementing a usuable HTTP-based REST server API and corresponding client layer for XIRUSS-T. This required me to extract interfaces for all the core SnapCM classes (something I should have done from the start but that's test-driven development for you--until I started on the client there was no need for interfaces because there was only one implementation of each class). This also required that I refine and fix the implementation of some core SnapCM semantics. Needless to say this was an involved refactor. Thank goodness for reasonably complete unit tests, that's all I've got say.

At the moment, the XIRUSS-T code in the Subversion repository on SourceForge now has a client API layer and corresponding unit test that can connect to a running XIRUSS-T server over HTTP, create a user, get a session for that user, get the user's session again, and get the same session. The client provides proxy objects that reflect the XIRUSS abstract API (thus the need for the interfaces).

This may sound simple but it was a lot of work to get this point. Now it's pretty much just a matter of typing to get all the client-side classes and methods implemented.

Once I have the client in place then it will be easy to create scripted or graphic clients to do stuff like navigate the repository, manage imports and exports, and so on. It will also make it easy to implement Layer 3 components as distributed clients, which is the most general thing to do even if they are running on the same machine as the server.

I really like the REST approach (using normal HTTP protocols and returning the result as XML chunks). I could have used something like RMI but that felt harder, even though it's probably actually less work to implement. But there's something very comforting about being able to point a browser at the server and see the XML response right there in the browser. Once you know the URL construction rules for the API you can navigate around manually. In the case of XIRUSS you can eventually navigate to the data content of a storage object version and see it in the browser.

It also means that code in any language can connect to the server--no need to somehow provide different language bindings (or be limited to only Java clients).

So I haven't had any time to write my next post in the XCMTDMW series. But I figure most people who are interested probably need some time to catch up to me anyway....