C binding to AstroRuntime

At the moment

At the moment AR has a RMI binding (only for JVM-based languages) and an XMLRPC binding. The latter can be called from any language with decent networking support. However, for some languages (C, Fortran), this isn't a comfortable interface, while other languages (IDL) don't have the necessary libraries and can't access AR at all.

Previous Attempts

Feedback from users suggests that the main target is IDL. We've already made 2 or 3 attempts to access AR from IDL

• Using the IDL-Java bridge - which essentially means running AR within the IDL process. Heavyweight to setup.
• Completing a partial implementation of an XMLRPC library for IDL. This has been on the cards for a while, various people have looked at it, and no progress has been made. IDL has very poor networking support, and struggles to parse XML - the current library seems to write each XMLRPC request and response to temporary files - which is inefficient. It also seems to only implement part of the XMLRPC standard.

Proposal

Produce a C interface library to AR, which can then linked into C, Fortran, IRAF, IDL programs. It could also be accessed from Perl or Python to provide a more 'native' interface, rather than going through XMLRPC. The benefit of this approach is a more strongly typed, native binding to AR in the client program, at the cost of increased setup & configuration required (compiling and linking to the C library).

Implementation

The C interface library will enumerate every function of the AR and present the same level of abstraction. Internally, a C XMLRPC client locates and connects to the AR in the conventional manner. Each function in the interface library is implemented by a call to the C XMLRPC client.

This implementation design decouples the binding from the AR itself (allowing existing programs to work with new versions of AR without recompilation) and doesn't require an additional access method to be added to AR - instead, it'll be using (and so robustifying) the existing XMLRPC access method. This, to me, sounds more workable that adding an JNI binding to AR, or using the RMI access method.

C libraries can probably be accessed from most languages without any additional work. However, SWIG should be investigated to see whether it's beneficial to produce language-specific bindings to the C library.

Code generation

The implementation of each function in the C library will follow the same boiler plate pattern - marshall arguments into XMLRPC library, perform call, handle errors, marshall results back to caller. This isn't the sort of thing which should be written by hand - here's how to automate it.

The AR API is defined by the Java interface classes in the desktop/api/src source tree. As part of the build, a custom javadoc task extracts a single XML file from all the interfaces. This file contains the names, parameter & return types, comments, and XMLRPC calling information for every function in the AR API. Later in the build, this XML api description is XSLT'd to produce internal deployment descriptors (used within hivemind in AR) and AR scripting documentation. These XLST have been pretty straightforward to write.

I'm confident that it's possible to write an additional XSLT that traverses the api description and generates C header and implementation files - containing boilerplate implementation and documentation. This would mean that the C library source would then be generated as part of the build, and would automatically track changes to the API.

Production & Packaging

I'm no C programmer. Don't know anything about Make. To use this C-binding, I'd want to do no more setup than type ./configure and maybe respond to a few questions - so the downloadable artifact should ship with everything required to build the C-library (plus SWIG bindings, if we're going that way). We should probably provide precompiled binaries for at least Windows and OSX too - as these lack a compiler by default.

There's going to be quite a lot of build machinery here, which I don't think belongs in the desktop/api project. Instead, I can place the XML api definitions in a zip in the maven repository, from where they can be fetched into a separate C-binding project.

Existing Resources.

Here's some existing work as a starting point:

• main.zip: John Taylor: the beginnings of a C++ AR client here. It requires no external libraries - all the source code needed is here in two folders.
• talk_to_acr_server.cpp: Richard Holbrey: C++ interface to AR

-- NoelWinstanley - 23 Aug 2007