From Tim Bray, tbray@textuality.com.

It took me years to realise how deep and important the divide is between wanting an SDK and wanting to know the underlying protocol. Too much of our biz can only see one of these realities. I grew up with networked minicomputers and (mostly) Unix, and maybe that's why, in the final analysis, I always want to see the bits on the wire, because in the final analysis, given any programmable device, I can work with them.

XML is of course the ultimate expression of that philosophy; it can do a reasonably good job of offering a bits-on-the-wire view of just about anything.

During the heydey of client-server I was repeatedly baffled and frustrated by the mind-set, in particular evidence chez Apple and Microsoft, that the only expression of computing reality was a big hairy complicated API with an associated big hairy complicated (and often expensive) SDK. This is not just a Unix-vs-PC thing - the X window system is one of the most extreme examples of the big, hairy, complicated, API (the rumor that they ever actually fully documented the wire protocol is false).

And not that this approach is wrong - I'm sitting in front of Windows box, and three of the windows are X applications running on my big server which off at a distant ISP.

These days I write big complicated software in Java, which does a good job of giving you a tractable object model overlaying insanely complex infrastructure. But in a distributed int[ra,er]-net scale app with heterogeneous boxes, there's still no substitute for the bits on the wire.

Our profession needs to grow up a bit and actually arrive at a consensus as to when each of these approaches is appropriate, teach it in college, and so on. -Tim