Four years of XML-RPC
Thursday, April 4, 2002 by Dave Winer.
Today is the fourth anniversary of XML-RPC. On this day in 1998, after a brief collaboration with Microsoft, we opened a new protocol to Frontier developers that allowed applications running on Windows to communicate with apps running on Macintosh, and vice versa. What followed exceeded my wildest expectations. Today, four years later, XML-RPC is the defacto language for interapplication communication on the Internet, with support in all popular development environments and operating systems.
XML-RPC evolved to become SOAP, which is more famous -- if you pay attention to the press and analysts and the execs at BigCo's. But if you listen to developers, they're choosing XML-RPC in droves, because of its simplicity, broad support, and lack of confusion about what it is and where it ends.
XML-RPC remains simple because I've been a hardass about simplicity. At the same time I continued with the SOAP process, and am one of its parents, because I recognize that it's important to connect with systems created by big companies, even if I despise their greed and aspirations to lock developers and users into their systems, which I do, and they do.
The breathless press reports say that this technology is revolutionary, and I believe it is, but not the way they say it is.
XML-RPC, emphatically, does not enable new applications. Anything you can do with XML-RPC could be done with any of the previous technologies that allowed applications to be controlled externally: COM, Apple Events, CORBA or CGI. In their day, these protocols were revolutionary because they turned applications into toolkits. Spreadsheets and page layout programs became platforms because of these technologies, spawning new developer communities, and giving new power to application developers and their users. XML-RPC is revolutionary in this way too, but it's not a new revolution, it's a replay of a revolution of the late 80s and early 90s.
If you're looking for something new here, it's that XML-RPC turns the Internet itself into a scripting environment. It makes it safe to not use the programming tools and runtimes supplied by the operating system vendors. Unlike the previous technologies, you are not locked into Windows, Mac, Unix or Java. There's a good chance that your app can communicate with any other app, no matter where it runs. It also makes it safe to choose a minority platform and communicate on equal terms with apps that run on previously dominant platforms. It undermines the hegemony of any platform that seeks dominance. This is why it was so courageous for Microsoft to take the lead in this technology. It's also why Microsoft is second-guessing this vision by promoting a Common Language Runtime, which is totally contrary to the philosophy of SOAP and XML-RPC, and should be approached by developers who value independence with extreme caution.
If XML-RPC achieves its promise, it will probably not, on its own, deliver any new products or features to users that wouldn't have been possible with previous connective technology. However, it will create new opportunities for small independent developers to come out of left field and create new applications that the Big's would never be able to get through their lugubrious development processes.
Yet the hype surrounding web services carries the opposite message, people who are supposedly experts in this area look to the Big's to produce the innovation, as if they have any track record of doing that. They don't, for good reason. I watched Microsoft's internal process chew up XML-RPC and spit out SOAP, a protocol full of second-guesses and hedged-bets; compromises that make it so complex you need to have a full-time engineer on board to keep up with the latest schema; where interop lasts months, instead of forever, as it must if the technology is to mean anything at all. The process of SOAP is sick, because it's dominated by conflicted big companies. Meanwhile XML-RPC keeps chuggin along, doing what they hope to do someday when they are finished, which seems can never happen.
I understand why Sun stayed out as long as they did, because their strategy was to be the uber-operating system. Why do we need choice when the only choice (according to Sun) is Java? Its internal method of connecting apps over the Internet only works with Java. I could see that this strategy would fail, but I think Sun can be forgiven for not seeing that.
The BigCo's, not just Sun, have a conflict of interest. They sell hundreds of millions of dollars of consulting work, that, with the advent of XML-RPC, can be bought for, at most, a few thousand dollars. They have a strong financial interest in clouding SOAP and XML-RPC in mystery. That's how they support themeselves, not by functionality, but through confusion. They have a conflict of interest that makes them bad husbands for open technology. Their interest forces them to push for confusion.
While the big companies fight over the rules of old and new consortia, and redefine SOAP every few months, the promise of XML-RPC is being delivered, in the wild free spaces of the Internet development environment, the platform with no platform vendor. No Senior VP's to be quoted, just independent developers working their butts off, creating new software; and users who are empowered and excited by the new applications they're delivering. Every day on Scripting News we report on this stuff. You probably won't find it in Infoworld, on News.Com or in the NY Times; no Forrester analyst will talk about it, because they haven't figured out yet that we can do it without any help from the BigCo's and we must, because they can't.
In September 1999, I wrote: "The purpose of XML-RPC is to end once and for all, the idea that there can or should be one operating system for all."
Today, more than ever, we need to reconstruct the software industry, not around the aspirations of big companies, but around new applications created by entrepreneurs. As XML-RPC enters its fifth year, there's much cause for hope that this will happen.