The State of XML-RPC, April 2001

After all the new movement in XML-RPC, I thought it was a good time to gather my thinking and let you know where I see it going. I'll take pushback, and revise this document as necessary through the day. These are my statements only, I don't claim to be speaking for anyone but myself and my company.

The indy wire protocol 

More and more XML-RPC is the wire protocol of independent developers.

In an ideal world there would be no wire protocol for anyone, or group of people, there would just be one wire protocol for everyone. But we've known for quite a while that this is not our idea of an ideal world. Accept things as they are.

Craig Burton, who was a leading thinker at Novell in the 80s and 90s counsels that there's nothing wrong with multiple wire protocols, and I agree.

Killer apps 

The quest for killer apps is moving along.

This morning three were announced.

Please support them any way you can, and develop your own.

Ideas are here.

I'd like to work with a search engine on an XML-RPC interface, asap.

Search engine app 

I'm mainly interested in using XML-RPC to coordinate the back-end of the search engine with the back-end of a content management system, to optimize dynamic sites like the ones we host. We get pounded, and most of the traffic is wasted. We want to work with the most aggressive crawlers, our users want their sites to be indexed, but we have to spend too much time and money to allow the crawlers in.

BigCo's 

I am lobbying the BigCo's to support XML-RPC in addition to SOAP 1.1.

If we play our cards right, they will, imho.

Fluidity 

Understand that this is a very fluid situtation, changing week by week, press report by press report.

Fixed 

While the world is fluid, XML-RPC must stay fixed, honed, more precise.

Emphatically, XML-RPC must not be fluid.

Its advantage is that what-it-is is well-known.

Forks 

Forks are welcome. However, especially if they are spun out of the XML-RPC community, I request, on behalf of the integrity of XML-RPC that they not in any way confuse people as to what XML-RPC is. This means being different, use different tags, a different object serialization format and most important, a different name.

Doing so will not make implementations more complex, but it will make the difference clear. No one is confused that SOAP and XML-RPC are different things, so we know it can be done. Please create another list and another website. Start fresh with a clean slate, and you'll get the goodwill of the community. Let's help each other. If it's done in a peaceful way, I'll be happy to help both forks.

Mascot 

It's time for a mascot.

Mike Donnelan came up with XML-RPC Man.

I like him a lot, makes a good balance to the dove, the olive branch and the United Nations.

We're for peace, but we kick butt.

Arf arf!

Interop 

Back to business..

SOAP is pulling ahead of XML-RPC in interop. If we want XML-RPC to compete, we must make an investment in interop. UserLand is going to take the first step, the announcement will come shortly from Jake Savin, who's been working on interop for us in SOAP.

Two priorities 

My top two priorities for XML-RPC for the moment are interop and apps.