Notes on XML-RPC vs MIME-RPC

MIME-RPC achieves better interop by providing type information for all data.
MIME-RPC can handle pointers and cyclic data structures, XML-RPC cannot.
XML-RPC is internally inconsistent and cannot be interpreted correctly.
All types are first class in MIME, XML-RPC does not handle types like XML or JPEG well.
XML-RPC forces the application programmer to coerce objects to and from wire level data. MIME-RPC uses content-type information to allow the application programmer to focus on the application.
XML-RPC does not interoperate with existing browser based apps. MIME-RPC does.
MIME-RPC allows the programmer to focus on the application rather than the wire. (Restatement of above)
MIME-RPC can operate over email. XML-RPC cannot.

Questions/Comments/Additions? Send email to alex@i2x.com

Why you need to send type information for all data?

You can't avoid types. Applications need to send data and that data may take a variety of forms. Unless both ends of the protocol know how to interpret that data errors will occur. MIME defines a type (and potentially an encoding) for all data transferred between applications. XML-RPC allows applications to send type information only for a limited set of types. All other types are passed without type information and base64encoded.

An annoying consequence of using XML-RPC is that users need to know exactly how data was sent over the wire so they can parse the base64 decoded data into some useful datastructure. MIME-RPC implementations can use the content-type to encode/decode automatically. One result (aside from the possibility of user error), is that XML-RPC applications can't overload functions to take different types because the recieving function has to know whether it is recieving e.g. a GIF or a JPEG in advance (or it needs a more sophisticated user-level algorithm for differentiating between them).

A more major consequence of using XML-RPC is that you have no mechanism to identify exactly what you are sending/recieving and therefore create large opportunities for interop errors. For example, if you want to send a set of 64 bit numbers, XML-RPC doyennes says you need to send it base64encoded. The problem here is that absent a document that defined a canonical form to be base64 encoded, that defines endianess, that specifies allowed spaces, charset, etc., there is no way to determine whether the base64encoded data was sent correctly (e.g. is 1000ABCDEF123456 acceptable or are spaces required; 10 00 AB CD EF 12 34 56). If you can send a content-type then you can refer to some document which specifies in great detail exactly what is to be sent so that both parties know.

Why you want Pointers and Cyclic data structures

So you don't duplicate data structures (saving bandwidth)

To communicate to the recieving application that two pointers represent the same object. For example, when sending a list of leaf nodes of a tree that contain pointers to their parents (e.g. an XML DOM or a representa tion of a class hierarchy), you want the recieving application to understand that two nodes share the same parent and not two identical but distinct ones.

To send cyclic data structures, like circularly linked lists or street maps or a a tree in which nodes point to their leaves as well as to their parents. e.g. this request to the XML-RPC list.

XML-RPC Spec Internally Inconsistent

The issue was discussed extensively on the XML-RPC list and resulted in a proposal for a lcdXML-RPC a new version of XML-RPC that fixes the problem. The proposal opens with:

    The XML-RPC specification document contains
    contradictory requirements for string
    handling. As a result, it is not possible to
    conform to it, and designers of individual
    XML-RPC systems have implemented both sides
    of the contradiction.

It describes issue with XML handling of ASCII data that make XML-RPC conformance impossible.

XML-RPC does not handle XML or JPEG well

The issue here is that it does not pass charset with XML and forces applications to base64encode JPEG even when the transport does not require it. This stuff in addition to the more basic issues with missing type information above.

MIME-RPC interoperates with existing browser based apps

The second example in the mimerpc_examples.cgi file of the mimerpc_python implementation is using MIME-RPC to request a MailToTheFuture from Dave's site.

It is an exercise for the reader to figure out how to use the same system to post to blogger or manila :-).

The general point here is that most CGI and Servlet libraries already process application/x-www-form-urlencoded, multipart/form-data, and multipart/mixed, so MIME-RPC clients can already talk to them. (e.g. MailToTheFuture). And most browsers already know how to generate these mime-types (form posts), so it is a simple matter for browser based javascript to make MIME-RPC requests to compliant servers. (e.g. one might post/read data from a hidden frame).

XML-RPC can't operate over email

Here is what I said on the XML-RPC list in December:

 Codepunk said:
 > Dave has already done xml-rpc over mail and I can also, nothing hard about
 > it.

 No he didn't and no you can't. It is not possible to do so.
 An XML-RPC request MUST be an HTTP request.

 In theory you could use email as a transport for XML-RPC transactions
 where the endpoints believe that they are just talking HTTP/1.0, but it
 wouldn't really work:
 * the client and server would need to keep the socket open for the
 duration of the email transaction -- which could be days if a human is
 involved with fulfilling the request!  Most HTTP implementations would
 time out.
 * XML-RPC client software would block on the request resulting in much
 hand coding of threads synchronization to get around that
 * You would need a protocol for binding emailed requests to emailed
 responses -- which you don't have.  MIME-RPC provides that protocol.
 * You would need another protocol for handling multiple replies to the
 same request.  XML-RPC does not allow that PERIOD.

XML-RPC cannot be used for asynchronous messaging. MIME-RPC can.

Last update: January 7, 2002 by Alex Jacobson
(c) Copyright 2001 i2x, Inc.
MIME-RPC(tm) is a trademark of i2x, Inc.