XML-RPC via SMTP
*** The reasoning
XML-RPC is designed to send a mime formatted message from computer to computer via a http connection.
But, not everyone has connections that allow for hosting of a http server (such as ERROR (pike)) on their client machine. For some applications, encapsulating the xml-rpc message in a mail message can be an effective substitute.
There are some issues that need to be addressed. An email message is a potentially unreliable asychronous method of connection. This means that for any given email, not only may it not get to the addressee, the sender doesn’t necessarily know that there was an error. By contrast, a http connection either works or there is an immediate error.
On the other hand, there are a lot of mechanisims for eventually delivering email to its intended destination, including retries and non deterministic routing. You don’t need to have both ends of the connection up at the same time. This is helpful if your isp is not.
That and I shot my mouth off at manilapalooza that this wouldn’t be that hard to do.
*** The spec
The request is of the form:
X-Mailer: UserLand Frontier 6.2b1 (Macintosh OS) (mailServer v1.01 .698) Mime-Version: 1.0 Date: Wed, 05 Apr 2000 18:53:58 -0700 To: rpcAddress@rpc.destination.machine From: reply@address.caller.machine Subject: rpc call to examples.getStateName Content-Type: text/xml; charset=us-ascii Message-Id: <20000406015305.D508F170044@mx.socialecology.com> < ?xml version="1.0"?>examples.getStateName 5
The essential portions of this are:
- To: addressed to a specified address. This is server and implementation dependent.
- From: The sender address. The sender may get a reply of the form shown below.
- Subject: Does not start with Re:
- Content Type: text/xml, to distinguish it from plaintext
- Body: this is straight from the rpc spec
A Sample Reply
X-Mailer: UserLand Frontier 6.2b1 (Macintosh OS) (mailServer v1.01 .698) Mime-Version: 1.0 Date: Wed, 05 Apr 2000 18:52:48 -0700 To: reply@address.caller.machine From: rpcAddress@rpc.destination.machine Subject: Re: rpc call to examples.getStateName Content-Type: text/xml; charset=us-ascii Message-Id: <20000406015156.C7E0C170044@mx.socialecology.com> < ?xml version="1.0"?>California
*** The implementation
I have three scripts that implement this client – server setup.
- The smtp-rpc client, analogous to betty.rpc.client
- The server side server, implemented as a mailserver filter
- A client side server, implemented as a polling pop client using Alan German’s tcpcmd (version 2.1.2).
The server side server requires a working installation of my “mailserver”. The Client side server requires tcpcmd and a script to parse the headers. This is suitable for installation in ERROR (pike). (In fact, that’s where it was put together.)
All of the scripts are attached (in a table) to this message.
*** The Demo
All of the standard Userland examples are installed on an rpc-email server at om@budda.om.wiredfool.com. It will reply via email. Note that it will only process messages that are of content type text/xml.
*** The Caveats
This is early stage work. It does work on my machine, and it may not resemble any known specification. It builds heavily on Userland and tcpcmd code.
*** The Legal Stuff
There is no warranty. There is no patent. If you use this code, you’re obligated to do cool stuff with it. This is posted with the permission of my employer, “Socialecology”.
5 comments
It might be useful to have some way to map a response to a given call with a call I.D. There are a couple of ways to go about this. One way would be to use a random “switch” token in the Reply-to: header of the request message, like:
Reply-to: reply+A035882BC9@address.caller.machine
The Mail Transport Agent should only use the part before the ‘+’ sign to route the mail, and leave the Mail Delivery Agent to switch on whatever comes after the ‘+’ (I use this in conjunction with procmail). You then specify that the XML-RPC reply go to the Reply-to: address.
Another way would be to use RFC-822 extention headers, for example:
X-XML-RPC-Request-ID: A035882BC9
It might be useful to have some way to map a response to a given call
with a call I.D. There are a couple of ways to go about this. One way would
be to use a random “switch” token in the Reply-to: header of the request
message, like:
Reply-to: reply+A035882BC9@address.caller.machine
I would actually be inclined to do this with the subject line. For example,
specify that the reply subject is the exactly “Re: ” + the request subject.
Alternately, the sending email address can be munged to have the message ID
as a portion. If there were any bounces from misdirected email, then there
would be some way to correlate that bounce with the correct call.
eric
Hmm, this looks really cool. My first thought was that someone has too much time on their hands, but then I realized that this was like an open competitor to MSMQ (Microsoft’s queued remote procedure calls system).
Now, does the From: address really need to be a special one? That would be bad for people who don’t have that type of control over their mail systems (like anyone who doesn’t own their own mail server). How can we get around that problem?
And just thinking about it a little bit, but can anyone think of any value in having xml-rpc via NNTP?
The Mail Transport Agent should only use the part before the ‘+’ sign to route the mail
Any idea whether most/all mail transports properly handle this?
Using a header should work as you’re using a program to read the mail. Where it might not work is if a human being was reading the mail and their client didn’t understand to use the header. Most wouldn’t and probably wouldn’t have any kind of choice to allow “preserving” the headers on a reply.
But, YES, the XML-RPC and SOAP protocols should be useable on more than just HTTP. Mail is but one other choice.
-Bill
Sendmail does, qmail uses a – instead of a +, don’t know about postfix. That probably covers 75% of the mail transport installations out there. I’d still rather key off of a subject line, since any mail filtering software can make decisions based on the subject.