Eric Raymond: XML-RPC is Unixish in spirit

Tue, Feb 20, 2001; by Dave Winer.

An email I received this morning from Eric Raymond. He said: "In a book I'm working on called 'The Art of Unix Programming', the following is part of a draft chapter not yet released."

Unix and Remote Procedure Calls: Why Discoverability Is Important

Until very recently, attempts to import CORBA and other forms of remote-procedure-call interface into the Unix world have largely failed -- these technologies have not naturalized into the Unix culture. The underlying reason seems to be that RPC interfaces are not discoverable; that is, it is difficult to query these interfaces for their capabilities, and difficult to monitor them in action without building one-off tools as complex as the programs being monitored.

The usual argument for RPC is that it permits ``richer'' interfaces than methods like text streams -- that is, interfaces with a more elaborate and application-specific ontology of data types. Unfortunately, interfaces that are rich in this way also tend to be brittle. If the type ontologies of the programs on each side don't exactly match, it can be very hard to teach them to communicate at all -- and fiendishly difficult to resolve bugs.

With classical RPC, it's too easy to do things in a complicated and obscure way instead of keeping them simple. RPC seems to encourage the production of large, baroque, brittle systems with obfuscated interfaces, high global complexity, and serious version-skew and reliability problems. Windows COM is perhaps the archetypal example, but there are plenty of others.

Andrew S. Tanenbaum and R. van Renesse have given us a detailed analysis of the general problem in [CR], a paper which should serve as a strong cautionary note to anyone considering an architecture vased on RPC. The general problems they dissect may indicate long-term difficulties for the relatively few Unix projects that use CORBA. Of these, perhaps the best known is the GNOME desktop project.

Unix tradition, on the other hand, strongly favors transparent and discoverable interfaces. This is one of the forces behind the Unix culture's continuing attachment to IPC via text streams. Because they have to be parsed, they are less efficient than RPC -- but the performance loss is marginal and linear, the kind better addressed by upgrading your hardware than by expending development time or adding architectural complexity. What you lose in performance by using text streams, you gain back in the ability to design systems that are simpler -- easier to monitor, to model, and to understand.

Today, the Unix attachment to text streams (on the one hand) and RPC (on the other) are converging in an interesting way, through protocols like XML-RPC and SOAP. While these don't solve all of the more general problems pointed out by Tanenbaum and Renesse, they do in somne ways combine the advantages of both text-stream and RPC worlds.

XML-RPC, in particular, is very much in the Unix spirit. It's deliberately minimalist but nevertheless quite powerful, offering a way for the vast majority of RPC applications that can get by on passing around boolean/integer/float/string datatypes to do their thing in a way that is lightweight and easy to to understand and monitor. This simple type ontology acts as a valuable check on interface complexity.

Chapters 1, 2, and 3 are available at http://www.tuxedo.org/~esr/writings/taoup/.

Thanks Eric. More here. Dave