scripting, object vs. document

Kragen Sitaker (kragen@pobox.com)
Sun, 31 Jan 1999 15:47:43 -0500 (EST)


On Unix, scripting a single application is often easy. Emacs has
elisp; the GIMP has script-fu and lots of other things; vi has its
language and recent versions let you embed Tcl and Perl; lots of
applications let you embed Tcl and Perl; and there are numerous
command-line tools you can use from the shell.

So writing a script that does something within a single application
isn't too hard. But on the Macintosh, it's relatively easy to write a
script that coordinates the activities of several diverse
applications. The script runs in a separate program -- a UserTalk or
AppleScript interpreter -- and "remotely controls" the applications.

This allows "software tools" to be built -- "tools" that do a single
small function that can be easily integrated into a larger
"application". This was indeed the underlying philosophy of Unix, but
the way it was implemented was document-based, so when people started
building object-based applications on Unix, they couldn't fit them into
this philosophy. So object-based applications on Unix are
traditionally huge and monolithic.

(By "object-based", I mean applications that encapsulate data with code
that gets run to access that data. Object-based applications are free
to store their data however they please; the only access to the data is
through the encapsulating code. "Document-based" programs, by
contrast, manipulate data in common, "published" formats that lots of
other programs understand. The difference is not binary, but
continuous.)

Remote scripting allows object-based software tools. Many object-based
applications, therefore, support it. Emacs has a "gnuserv" facility
that lets you connect to a running emacs process, hand it an elisp
expression to evaluate, and get back a return value or error
condition. All Tcl/Tk-based applications can accept Tcl expressions to
evaluate, and return a return value or error condition. (The command
to do this in Tk is called "send". See the "rmt" example application
that ships with Tk for details.) GNOME applications are all supposed
to support a CORBA interface that lets you automate them, too, and KDE
is jumping on the CORBA bandwagon. Even Netscape has four or five
functions you can call by setting X properties on its window -- I don't
remember if they can return results.

The trouble is, all these different methods of scripting do not
interoperate. Emacs, and the dozens of powerful applications running
within it, speak Lisp; Tcl/Tk applications speak Tcl; GNOME
applications speak CORBA. What we need is a general facility that lets
us send function calls in a uniform format to all of these applications
and receive results -- values or errors -- in a uniform format. Then
we'll be able to easily write scripts that coordinate the activities of
all of these applications at once.

There's such an "interchange" format, called XML-RPC, that Dave Winer
is pushing. I think it's going to take off. (See www.scripting.com
for more.) There's already support for it in software Userland has
been shipping for a year, and also in Perl, Cold Fusion, Java, and
Python.

What we need is a proxy server that accepts XML-RPC calls, translates
them into Lisp expressions, CORBA calls, or Tcl expressions, and
forwards them to the appropriate applications. Then it takes the
returned results, translates them back into an XML-RPC response, and
sends them back to the caller.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- philg@mit.edu