[Swig-devel] Using SWIG for generation of RPC interface?

[Waschk,Kolja <sw...@ix...>]

Hi,

I'm quite new to SWIG, but from all documentation and some small
experiments I think it's well suited to help me with the generation of
interface code for the UrJTAG project. So far, nothing new - we want Perl
and Python interfaces for that library etc...

Now I also plan to "export" the future API of UrJTAG over communication
links, e.g. TCP/IP network connections, USB etc., and would like to ask
here if someone already ever considered to use SWIG for a similar
project, and whether you think it's feasible or not.

Ideally, an application that currently calls some function of a locally
linked instance of the UrJTAG library could be enabled to call the same
function but on a device far away. It just would have to link to a
variant of the library that exports the same API, but instead of
implementing the functions itself it just does some kind of remote
procedure call to a server for the real work.

It may be possible with an extended SWIG to save a lot of coding
of wrappers that glue original functions of the UrJTAG library with
generic communication code, and the implementation of an API to the
communication code (on the other side of the link) that can be used
almost like the original library API.

Without going into detail of the URFP(*) protocol, there are two
tasks where SWIG might be useful.  On one side (the client side that
wants to call remote functions), the original function has to be
replaced with something like this:

  1. encode arguments for transmission over communication channel
  2. transmit encoded function call
  3. wait for results and decode them

On the other side, the server side awaiting requests to perform tasks,
code has to be created to perform the following tasks:

  1. decode arguments from received requests
  2. call the actual library function
  3. encode results from the function for transmission

SWIG extensions to create [much of] that code would simplify the process
of developing firmware and device drivers for many types of "connected
devices". It could be as simple as this:

  1. Write library
  2. Write interface definition
  3. Use SWIG to create all the following (assuming that SWIG extension
     and generic communication code already exist):

   a) Interfaces to script languages for linking directly to the library
   b) Server code that exports functionality over various interfaces
   c) A client library that can call the functions remotely, and
      which can be linked as a drop-in replacement for the above library
   d) Interfaces to script languages for linking to the client library.

Thanks for your comments and ideas in advance!

Kolja Waschk

(*) URFP draft: http://urjtag.wiki.sourceforge.net/FutureProtocol

-- 
Mr. K. Waschk - http://www.ixo.de - Hamburg, DE