[untitled]

July 29th, 2001

Seditious thought for the day: Is the phrase ‘Strike while the iron is hot’ really a call for industrial action amongst housewives?

[untitled]

July 28th, 2001

Tom Bradford’s ‘The Future of XML‘ is a timely warning. Perhaps the motto for the W3C should be one of my favourite quotes, taken from Antoine de Saint-Exupery:

You know you have reached perfection in design, not when there is nothing more to add, but when there is nothing more to be taken away.

[untitled]

July 26th, 2001

There is a quote from Byte at the top of the XML-RPC home page:

“Does distributed computing have to be any harder than this? I don’t think so.”

No, it doesn’t have to be, in many cases. I’ve just been making my first real use of XML-RPC, and it was perfectly adequate for my needs, trivial to install (at least for Python) and to debug. It’s also very easy to learn, especially if you understand XML; the entire spec is just a couple of pages, written in a very laid-back Dave Winer-ish ‘this bit isn’t defined, it’s application/implementation-dependent’ style which would probably make writers of most other technical specifications begrudge it the name.

The big question, then, is what the other systems like SOAP, Java RMI, and more particularly CORBA, give you that make them worth the steeper learning curve, the installation hassles, and the devotion of large areas of bookshelf to ‘real’ specifications.

Well, you get performance, for one thing. It would be hard to define a less efficient method of sending certain types of data around than encoding them as a structured text document and using a general purpose parser to decode them at the other end. But unless speed is an absolute requirement for you, other factors are likely to be more important. Ever written a shell script, a Perl program, a Java application when you could have used C? Precisely. Developer time is more expensive than processing power.

But with many of these other systems you also get a raft of services that XML-RPC doesn’t try to provide. Callback mechanisms, interface discovery, security, naming services, to mention a few. You also get a more thoroughly-defined agreement between server and client as to what the nature of the interaction is going to be. All these things add complexity, which is what makes other RPC systems more difficult to learn, but it’s complexity you may have to implement yourself if you’re building substantial mission-critical systems based on XML-RPC.

So the XML-RPC premise is that most distributed systems aren’t like that. That the required interactions are typically simple things and don’t need the complexity that something like CORBA can bring to your development. That the relatively slow speed of the internet or of user interaction makes the speed of the RPC system irrelevant. For the sort of stuff I’m doing, this is usually true, which is good because it means I can spend less time worrying about the plumbing.

So, should you use XML-RPC? I guess the answer is ‘application/implementation-dependent’…

[untitled]

July 8th, 2001

My trusty old Palm V died recently, and I’m trying to switch to a Compaq iPAQ as an experiment. You can read about my experiences in “How I survived the move from Palm to Windows CE“!