And XML is definitely not suitable as a marshalling format for a RPC
protocol.
XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless
moron.
Hmm. Well I think there are a lot of very smart developers that are
using xml to marshal rpc and it's working fine. So either they know
something you don't, or maybe they are just busy making code that
functions and functions pretty well, instead of making inflammatory
statements on USENET. Sure XML is not very efficient or compact, but it
does handle unicode intrinsically through standard encodings, and a
plethora of parsers makes it a decent choice. It's like what they say
about the book: "for though it has many omissions and contains much that
is apocryphal, or at least wildly inaccurate, it scores over the older,
more pedestrian work in two important respects.
First, it is slightly cheaper; and second, it has the words Don't Panic
inscribed in large friendly letters on its cover."
I've used LBER-encoded wire protocol before, and it was fine, but hard
to debug on the wire, and didn't haven anything in it to handle unicode
except base64-encoding utf8 byte streams.
That said, all this reminds me of a good saying, "XML is like violence;
if it doesn't solve your problem you're not using enough of it."
Fortunately none of this really matters. Who cares what is used to
marshall RPC over the wire? As a developer I certainly don't care. I'll
use whatever is convenient and well supported. One reason I do like
xmlrpc, though, because it's pretty much available to all web-based back
ends for free (or at little cost) and you don't need to set up a special
server process to handle it, or deal with odd port numbers that might be
blocked, doing ssl yourself, etc. Having HTTP do the transport frees me
from having to worry about all that, since in the case of a web app I am
already using a web server.
