Foreword to O'Reilly's XML-RPC Book
Thursday, May 17, 2001 by Dave Winer.
It appears I've got a new business -- writing forewords to books I believe in.
It doesn't pay very well, but it's gratifying work. Late last year I wrote the foreword for Joel Spolsky's book on user interface design for programmers. It will be released from Apress later this month. Highly recommended.
In April, technical book publisher O'Reilly Associates asked me to write the foreword for their upcoming book on XML-RPC, a protocol I've been working on and promoting since 1998. Here is a copy of the foreword lightly edited for email distribution. There's a link to the O'Reilly catalog at the end of the piece where you can order a copy of the book.
My name is Dave Winer. I wear a lot of hats. I'm the CEO of a company, a programmer, a columnist, weblogger, and a developer of things that turn into standards. The last role was the biggest surprise. I've been developing software since the late 1970s, and all the time I wanted most to create a standard, to develop something that's so compelling and simple that its goodness propels it to success. I'd say now, with XML-RPC becoming such a widely adopted protocol, that it's happened. It's a strange feeling, for sure. Here's how it started.
In 1998, my company, UserLand Software, had just finished porting Frontier from Macintosh to Windows. Our software made extensive use of networking, so we had a problem -- with two versions of the software, how would they communicate? We could no longer use the networking software of one platform, Apple Events on the Mac, or DCOM on Windows. So we decided to use two standards of the Internet, XML and HTTP, to form the communication protocol for our software. By January 1998 we had a deployed protocol for Frontier-to-Frontier communication simply called RPC, and it worked pretty well.
As I often do, I wrote a public essay about this and offered to work with others. Usually I make those offers and no one responds. This time, I got a call from Bob Atkinson, who I knew from work we did with Microsoft on COM in the early 90s, and he asked if we would like work with them on XML-over-HTTP. I remembered that it had been a lot of fun working with Bob in the past, so without hesitation, I said yes.
I flew up to Redmond, met with Bob and met Mohsen Al-Ghosein and Don Box for the first time. We sat in a conference room, I had a projected laptop. I opened Notepad with an example call from our earlier protocol. As people expressed their ideas I changed the example. It was one of the most productive brainstorming sessions of my career.
A few weeks into the process I wanted to release the software to our users. It was already much more powerful than what we were shipping. Wire protocols are a delicate area, and serious breakage would surely happen if we waited much longer. So we forked a release, called it XML-RPC, and continued working with Microsoft on what would become SOAP 1.1.
But that's another story and another O'Reilly book. ;->
As Edd and Simon explain so well, XML-RPC is XML over HTTP, and a great way to develop Web Services. But there's actually more going on here, there's a philosophy to XML-RPC that's different from other software projects. The philosophy is choice, and from choice comes power, and, interestingly, a disclaimer of power.
In the past, your choice of development environment limited your power as a developer. If you chose to do Java development, that meant, for the most, that your code could only communicate with other Java programs. Same was true of Microsoft and, in practical terms, many open source scripting environments.
However, when you build applications with XML-RPC as the connecting glue, all of a sudden you're not locked in. If you want to switch from Java to Python, for example, you can do it gradually, one component at a time. This kind of fluidity allows developers more choices, and relieves platform developers of the responsibility of being all things to all people. By supporting XML-RPC the platform is offering you a way out if you don't like the way they're going. Choice here is power for developers. We've learned the lessons from lock-in, XML-RPC takes it the next step, where it's supported you are guaranteed choice.
Having XML-RPC in place also means that new environments can come along, and even if they don't wipe out all previous environments (they never do of course) they can still find a user base that appreciates their qualities, and their work can interoperate with the larger environment.
Viewed another way, XML-RPC turns the Internet itself into a scripting environment, much as Visual Basic turned Windows into a scripting environment, or AppleScript turned the Macintosh OS into one. It makes our worlds come together, makes the bigger world smaller and more approachable. And it's inclusive, no one need be left out of the XML-RPC revolution.
And you can pick it up by a different thread and it's one of the most ambitious and successful open source projects in history. Most of the XML-RPC implementations are open source. Leaders of the open source world from Eric S. Raymond to Tim O'Reilly are big fans of XML-RPC. The Slashdot guys love it. Why? Because it's simple, low-tech, and it gives developers freedom to choose their development environment.
The joy of XML-RPC, for the programmer and designer is that we can learn how other people do what we do. I know almost nothing about the non-UserLand implementations, yet my software is part of the network defined by all the languages that support XML-RPC. It's like visiting a foreign country where they don't speak your language. They still eat and sleep and do all the other things we all do, but they do it differently. It's a passport that takes you anywhere you want to go.
So in my humble opinion, XML-RPC the ultimate leveler. It teaches us about each other, it's what we have in common. Perl, Python, Tcl, C++, Java, Microsoft, Sun, O'Reilly, sole proprietors, LittleCo's and BigCo's, open source teams, consultants and contractors, everyone can be on the bus, everyone can contribute to the environment and benefit from it. Sure, it's also XML-over-HTTP; but it's also a ticket to freedom and power for all developers.
Here's a list of issues that are on my mind re XML-RPC in April 2001.
Apps. As we continue to work on interop, we're also creating public services in XML-RPC. For example our Manila content management system has a full XML-RPC interface, as does xmlStorageSystem, and mailToTheFuture. This means that every Manila site is a server that you can run XML-RPC scripts against. There are so many cool things we can do here. The apps are linked into the Services section of the XML-RPC directory. The list is relatively short now, one of our goals is to make the list really big.
Tools. One of the most exciting possibilities of XML-RPC is that writing and illustration tools can seamlessly connect to servers, turning the Web into a fantastic easy creative environment, open to all.
Deployment. I'd like to see scripting environments bake XML-RPC into their releases. Networking is an important function for all developers, UserLand has included full XML-RPC support in all of our products, and encourage others to do so too.
Community. Please join the XML-RPC community. We have an active mail list and website, all the resources are pointed to from http://www.xmlrpc.com/.
Finally, thanks to O'Reilly for supporting the XML-RPC community with such an excellent book.
And thanks to Edd Dumbill and Simon St Laurent, for studying and understanding and documenting XML-RPC in the depth they have. Such commitment and talent is rare, we're really lucky to have them working to make XML-RPC more broadly accessible to Internet developers.
Now I turn you over to their capable hands. I hope you enjoy XML-RPC and join the community, and let's use XML-RPC to create a fantastic new Internet scripting environment.
PS: I'm going to Europe next week, planning a Scripting News dinner in Amsterdam on May 26. If you can come, please do. Watch www.scripting.com for pointers to the place and time.