Lightweight IPC for scripting

As many people by now have the misfortune to know, one of my pet rants
about Unix as a desktop OS is the lack of decent support for scripting
applications.  Some apps do CORBA, some apps listen on sockets, some
apps reread their config file when sent certain signals, some apps you
can start twice and the second instance will communicate its command
line args to the first, and some apps (e.g. GNOME, KDE stuff) use some
vast framework which handles it all in a
you-shouldn't-care-about-the-internals way

None of them have seen pervasive uptake, which makes me feel better
about inventing yet another.  sexp-ipc (working name, which needs
changing if it's ever to appeal to anyone outside of Lisp ;-) has the
goals of

 - designed for 'scripting': sending fairly high-level commands to
   applications.  For example, you might send 'mute' or 'play tracks
   3-6' to your cd player; you might send 'load foo.png, add label at
   (100,100), save it' (that's three commands) to a graphics editor,
   or you might send 'gnus' to your emacs

 - talks to the apps that you can see on the screen (as opposed to the
   apps running on your machine, or local network, or local filesystem,
   or under your uid, or ...).  We achieve this by communicating via 
   X properties; this also gives us security (or as much security as
   the user already has, which may not be the same thing) via xauth
  
 - implementationally lightweight: shouldn't be more than a few
   screens of code to implement; certainly shouldn't require buying
   into some large library or framework.

The sample you see a link to here is the result of about a day's
hacking, mostly composed of leafing through the documentation, sudden
redesign decisions, and distractions.  I don't claim to be an Xpert or
a CLXpert; anyone who can suggest better ideas is welcome to.  Anyone
who can tell me it's full of X protocol races, likewise.

Notes

0) This is proof-of-concept code only

1) The format for commands and their responses is text-based: anything
   sent through the interface in either direction must be able to
   survive print/read

2) It uses READ, which is OK I suppose, but it really should specify a
   more restrictive language than "whatever cl:read accepts": for
   example, are authors of C implementations going to want to write a
   reader for rational numbers, or complex numbers, or whatever?

3) It uses EVAL, mostly for demonstration purposes.  Most actual apps
   probably want to write some mini-interpreter, or at least to use
   something like the Tim Bradshaw package hacks to lock down the
   interpreter. 

4) It "flattens" errors: presently, all you're going to get from an
   error is a piece of text.  This may actually be sufficient: Perl
   has managed for years with regex-parsed errors, and HTTP for nearly
   as long with only two commonly-used errors: "page not found" and
   "internal server error".  But still, it gives me the creeps.

5) The REMOTE-EVAL function takes a window ID.  There isn't yet any
   way to decide which window id is the appropriate one to send a
   given request to; obviously searches by application name or class
   would be a place to start. 
   
6) Read source code for other observations and an overview of how it
   works (in summary: combination of X client-messages and properties)

I took a screenshot, because it's the done thing.  Then I added arrows
and stuff in the Gimp, so it would look prettier.  See

          http://ww.telent.net/sexp-ipc.png

(probably not a permanent url).  In the screenshot

 - emacs on the right is running SBCL is running the server.  Observe
   that it has printed its window id out (red arrow)

   the window is one of the two small unrendered things in the top left

 - the client is running in another sbcl in the xterm on the left.  It
   has a window just like the server

   we've made three calls to the server: a simple evaluation (result
   returned as answer), a form with side effects (displayed in server
   window: green arrow), and a form that signals an error.  Note that
   although we get an error in the client, it's only a simple-error:
   we get the text of the error message from the server, but can't get
   backtrace or any further detail.

   We're not presently doing any parsing of the result.

 - the other (partially obscured) xterm near the top of the screen
   with the xprop command in it (circles in yellow) is showing the
   properties on the client window.  See that one of them is actually
   the error from the last form we attempted to evaluate.

Sample source code in http://cvs.telent.net/cgi-bin/viewcvs.cgi/sexp-ipc/

I should probably write at least a Perl version at some point, if not
a C one.


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources

_______________________________________________
Clump mailing list
[email protected]
http://manly.caddr.com/mailman/listinfo/clump

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA/WpCJHDK5ZnWQiRMRApm0AJ9CDA+dy3SAosM4FRJQjADG0QHLDACfT4Ih
0ENXLtNyJ08QS/yXP/+taNw=
=w+Sj
-----END PGP SIGNATURE-----