Comment by ekidd | Hacker News Reader

Comment by ekidd | Hacker News Reader

Parent Full thread

What was XML-RPC attempting to solve?

That's an excellent question! To answer it, we need to rewind to the year 1998. Nobody had ever heard of JSON (2002) or REST (2000) or SOAP. If you wanted to do remote procedure calls, you needed to use Sun RPC or Corba or another binary RPC stack. Some of these required tens of thousands of lines of C code to implement, and I don't even want to think about the security issues.

Basically, XML-RPC was trying to be REST+JSON before that was a thing. It had already been implemented for most scripting languages, but one of my consulting clients needed a C implementation to interoperate, so I wrote xmlrpc-c in a couple of busy weeks around the end of 2000, I think.

Back in those days, XML had a very clear 30 page spec and XML-RPC had a 2 page spec. If you want to argue that I was wrong to use C to implement 32 pages of pretty good specs, or that I was wrong to use the best off-the-shelf XML parser of the day, well, I agree. But I think we need to demand more from our system languages.

> To answer it, we need to rewind to the year 1998. Nobody had ever heard of JSON (2002) or REST (2000) or SOAP.

But people had heard of S-expressions, which are far more appropriate for data transfer than XML.

And the canonical S-expression spec, from 1997, is rather less than 30 pages: http://people.csail.mit.edu/rivest/Sexp.txt

I think one could actually argue that all RPC protocols have ended in unmanageable disaster, and that the only things that endure are IETF-style protocol-first human-readable systems. However, that would take a lot of argument which I'm not committed to.

I looked at XML-RPC when it came out, and knew instantly that it would be a disaster. Even when you took out the XML-ness, the underlying concepts were complicated, badly explained and open to a ton of wiggle room.

Then you add the inefficiencies of XML encoding, and the utterly crappy nature of most XML translation layers . . . yeah, really easy to see the train wreck coming.

Sure, XML-RPC not the best protocol. Compared to others it's pretty simple, and the mess and number of edge cases is smaller than SSL or TCP/IP.

If C isn't up to implementing an only slightly complicated network protocol, it's not much of a systems programming language, is it?

It turns out, C is fine for writing such systems and getting them working fairly well, but very poor at making them really reliable and secure, and that's no longer a good tradeoff.

Reply on news.ycombinator.com