XML is not necessarily the answer
Joe Shaw wrote about XML and Google’s Protocol Buffers, which I admit I hadn’t heard of before today, but it’s pretty irrelevant what the debate was, XML versus Protocol Buffers or XML versus Pink Fairy Protocol or whatever. The point he makes very well, and the point which is very important and, I feel, not appreciated very much in the wider Internet, is that XML is not suitable for everything.
I’m not going to say much more, because I can’t make the point any better than he did, but the point is a good one. At work I designed a simple prefix-based ASCII protocol for two servers to use to talk to each other. Much more lightweight than XML, much easier to encode and decode, and you only need the first few bytes of a message to figure out if the message is incomplete or not. And you can transmit pretty much anything with it. It’s even human-readable, to a certain extent – you need the protocol spec in hand (or you have to know it) but you can figure out what a message is trying to say.
Estimated bandwidth saving over using XML? I reckon it’s about 30% lighter than a reasonable XML application to do the same job.
XML does of course have its place, and having tools like XSLT and XPath available to play with structured data is great, but sometimes you don’t need it, and sometimes you just can’t take the bandwidth hit, because like it or not XML gets verbose very quickly.
This post brought to you by the thinking about work on a Sunday society.