Re: Kate Rhodes' Comparison of XML-RPC and SOAP

Thu, Nov 15, 2001; by Dave Winer.

There was a brief discussion of Kate Rhodes' comparison of XML-RPC and SOAP on the Soapbuilders list yesterday. Two key bits of pushback from Rich Salz. He didn't like the use of the term "Big Co" and he said that SOAP could be used to transmit XML.

Now, I think the term BigCo is OK, but it's totally up to Kate whether she thinks it's appropriate in her piece. Personally, the reason I keep up with SOAP is that I want my software to interop with BigCo software, and since they use SOAP, that's why I am willing to support the added cost and overhead of supporting two XML-over-HTTP protocols in our environment.

It's important to note that not all developers agree, notably Eric Kidd, the developer of the C/C++ XML-RPC toolkit. But we all have to make choices for ourselves. In my case the BigCo-ness of SOAP is a very important consideration, weighing in favor of SOAP. I'm not sure the BigCo people even understand that. Their support for SOAP is keeping it afloat.

Further, XML-RPC can also be used to pass XML in parameters. We do it all the time. In fact, the document you're reading right now, is transmitted from my desktop machine to our Manila server over XML-RPC in OPML, which is XML. Bing.

Now perhaps the purists think the way we do it is too hackish, but it works. I'm not in the purity business, I like systems that work, today, not ten years from now and not only with BigCo servers.

This goes to what Brandon Wiley said yesterday, so well. I've quoted him in full here, it's an important perspective, one that I fully share (even though I think everyone should edit in Radio, not emacs or PowerPoint). I can support Brandon because we are in philosophical agreement -- choice should be with the user. This is not a philosophy that's adopted fully by Microsoft and other Bigs.

Graham Glass said: "The learning curve for a SOAP implementor is certainly not short, but the complexities of SOAP should be completely hidden from a regular developer by whatever web services platform they are using. If the review is being written for an audience of general developers, then I would argue that many web services platforms already make the learning curve for SOAP very small."

This is a good point, and one that I agree with. However, the same is true of XML-RPC. How much complexity does each pass up to the developer who uses a toolkit? If they're being used to do the same thing, they pass up the same amount of complexity. We can see that clearly in our development environment, which hides the details of both protocols behind a single interface. However, if you use SOAP for routing and actors, etc, I don't imagine it would remain very simple even for a developer who's using a toolkit.

Further, simplicity is important even for developers who use toolkits. I like to be able to look at and understand what's going over the wire. It helps me grok the whole system and feel comfortable that I'm not being locked in. Further, since I am one of those toolkit developers, complexity simply costs me money. I have to pay programmers to write and maintain the code.

Brandon Wiley's comments 

These comments appeared yesterday on Brandon Wiley's weblog. It doesn't have a permalink (that I can see) so I reproduced his comments, in full, verbatim. They're important.

"I was just pointed to a most amusing entry on the O'Reilly weblog site. I did in fact talk to this guy in the speaker room. I was making my slides with SVG because every conference I make my sliders with a new non-powerpoint technology in order to demonstrate that people have options when it comes to such things. He offered to license me a copy of PowerPoint, to which I replied that a copy of PowerPoint XP would be useful in increasing my status among the warez kidz on IRC but that I was still going to do my slides in SVG because I was trying to make a point.

"Then he tried to get me all psyched up about doing an open source implementation of Hailstorm, as he says in the article. This was about as effective as it would have been had I tried to convince him to switch to Emacs for all of this editting needs. However, it was a fun and amiable conversation. He seems like a really nice guy who is just deluded into thinking that Microsoft is really cool and good. I find that to be a tolerable quality as I myself am deluded into thinking that Linux is usable by the average person.

"In actuality, it might be possible to convince me that Hailstorm on Linux might be a good thing. Sometimes Microsoft pushes things to the point that they become widespread enough to be worth implementing. The only examples I can think of are the RTF and Windows Bitmap file formats. I would also start using SOAP if they finally managed to squash XML-RPC by sheer force of marketting as SOAP is the next best thing as far as I can tell. So if Hailstorm ever became ubiquitous then it would be as reasonable to implement on Linux as SMB and VFAT. However, I'd prefer that it not become ubiquitous. Helping out the Microsoft hegemony just encourages them. We shouldn't encourage them because they are very naughty with their attempt to make things proprietary and non-interoperable. If they really want Hailstorm to be adopted then they should play fair and give the other kids a say in the standard.

"In the meantime, I'll do doing just that by collaborating with other P2P hackers on the Tristero APIS."

Eric Kidd's comments 

The SOAP BDG interoperability document describes a very reasonable subset of SOAP.

The full standard, however, is too complex to be implemented by in-house or part-time developers, which significantly limits interop with custom enterprise systems and obscure programming languages.

If I were making money off of XML-RPC for C/C++, implementing the subset of SOAP described in the BDG would be one of my major priorities. Implementing full SOAP 1.1, however, would offer relatively little benefit for the work involved.