XML-RPC and http

[Dave Winer]

This is probably going to blow some peoples' minds -- but Mark raises some
valid points, the most significant being that the payload of an XML-RPC (or
SOAP) message is different from the normal payload of an HTTP-POST.

Clay, you are also onto something. The interfaces in scripting languages for
XML-RPC are native to the environment they're running in. So while it's
usually possible to lift the hood and see what's actually going over the
wire, you don't have to. In the best case, which is probably Python, you
just make a procedure call and the system takes care of routing it to the
other machine, which might not be running Python. On the other end, the
receiver is talking XML-RPC in the terms most comfortable for their
environment.

The beauty of this stuff is that it's such a nice zig to .NET's zag.
Microsoft's philosophy is to integrate all languages into a common runtime.
That's certainly a valid approach. But many of us prefer the programming
environments we've gotten comfortable with, there's no desire to switch to
another, and no need to, as long as you can communicate between environments
with a common protocol.

It's also a zig to Sun's zag. Until this stuff came along, RMI was the only
way in and out of Java, and for whatever reason, RMI only ran in Java.

So at a level that Clay Shirky might care about this stuff -- it's the
anti-locked-trunk approach to integration among diverse programming
environments.

SOAP and XML-RPC both do this. The difference, from my pov, is that SOAP has
the backing of very large companies, and XML-RPC does not. You may find that
to be a feature or a liability depending on how much faith you have in big
companies. I choose to support both.

It's also interesting is that Microsoft probably supports the philosophy of
diversity. At a business level they appear to have put all their eggs in the
membership basket. Yesterday I talked about this with Eric Raymond and we
immediately agreed that it's time for an open alternative to Passport. And
because of Microsoft's ambivalence to integration-vs-diversity, it should be
easy to get their environment to support a new membership network.

BTW, when the open source convention is going on, I will be across the
street at a conference for corporate IT strategists run by The Burton Group.
Craig Burton will be there too. Maybe we can get together for a BOF session
one evening and get deeper on this stuff. I guess that depends on how open
the open source convention is. ;->

Dave



----- Original Message -----
From: "Clay Shirky" <clay@shirky.com>
To: "Mark Baker" <mark.baker@sympatico.ca>
Cc: "Clay Shirky" <clay@shirky.com>; <fork@xent.com>
Sent: Wednesday, July 11, 2001 8:22 AM
Subject: Re: XML-RPC and http


> > In there are several XML-RPC methods called "get" (e.g. manila.css.get,
> > manila.customPrefs.get, manila.editorialOutline.get).  Now why would you
> > want to do something that clearly aims to do what an HTTP GET does, over
> > an HTTP POST?  You lose so much by doing this.  You lose the ability to
> > use HTTP proxies (say, to have that content cached).  You lose the use
> > of HTTP authentication (see how those Manila interfaces require a
> > username and password?).  You are basically starting from scratch with a
> > new protocol.
>
> Aha! Now I think I get what you are trying to say.
>
> You would use XML-RPC for the same reason you use SQL. With SQL, you
> give up the ability to interact with the DB file directly, in return
> for which you get to handle all your semantics in one package. You
> would use XML-RPC because you give up the ability to interact with the
> transport mechanism directly, in return for which you get to handle
> all your semantics in one package.
>
> Note that I am not educated enough about XML-RPC vs SOAP to advocate
> one over the other, just that the argument for abstracting away lower
> level details in order to be able to have a unified "work space"
> applies in many places -- C vs assembly, perl vs C, and so on.
> Sometimes you want to work in assembler instead of perl, and sometimes
> you will want to optimize the http as well as the message, rather than
> encoding everything in the message body. But lots of times you won't.
>
> If a novice programmer can pick up a book about XML-RPC and begin
> programming without having to keep track of what is handled in the
> message body and what in the underlying transport, that is a
> potentially big win in the 'conceptual ease of use' category.
>
> -clay
>
>
>
> http://xent.com/mailman/listinfo/fork