XML-RPC and http

[Mark Baker]

Clay Shirky wrote:
> 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.

It's much worse than that.

Take a look at the rest of the Manila interface.  There's several "set"
methods (manila.css.set, manila.customPrefs.set, etc..).  HTTP also has
an equivalent to set; "PUT".

It also has other more specific get methods such as
manila.editors.getStoriesHeaders, and manila.editors.getTable.  These
can also use HTTP GET, just on different URLs, e.g. GET /StoriesHeaders,
GET /Table.

The end result being that any well designed RPC interface will
eventually look a heck of lot like HTTP's methods (GET and PUT at least,
POST requires more squinting), in large part because interactions over
the network should be coarse grained.

So then you have to wonder why not just use the HTTP methods instead of
your own private RPC methods.

> 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.

Less than you'd expect, because HTTP's application semantics (the
meaning of "GET", "POST", "PUT" are so darned generic).

> 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.

Ditto for HTTP.

Ok, I'm getting back to my same arguments again that the rest of FoRK
has probably had enough of.  I'll stop.  We can take this offline if you
like.

MB