Protocol transitions are hard.
Yeah, I know the experienced software developers reading that are thinking “Well, duh!“. Shut up already, I’m venting here. I’ve just spent the better part of two years – actually, if you include design time and false starts it could be closer to five years – designing a new application protocol for my gpsd service daemon, implementing it, getting it deployed, dealing with problems and course-correcting.
For those of you in the cheap seats, an “application protocol” is a kind of language that a program uses to communicate with other programs. Normally humans never see these, but there’s one big example that non-geeks have often seen bits of. HTML, the Web’s markup language, is an application protocol. Designing these is not easy. There are difficult issues and tradeoffs around flexibility, economy, expressiveness, and extensibility for uses we haven’t imagined yet.
When you have a whole bunch of programs written by different people communicating with a particular application protocol, changing that entire ecology to use a different one is not easy. A good analogy in the physical world is the difficulty of changing an entire country’s railroad gauge. The long-term benefits may be huge, but the short-term cost in capital and service disruption is daunting.
Sometimes it has to be done, though. The old GPSD protocol wasn’t extensible enough, and it had some bad design decisions baked into it. Hackers can read a more detailed discussion of the technical issues in my white paper GPSD-NG: A Case Study in Application Protocol Evolution.
It took me three years of thinking and experimenting to get to the point where I had a new protocol design I was happy with. Took me nearly two years after that to implement it, debug it, get it deployed, figure out where I’d made some minor design errors, and fix those. Did I mention that this sort of thing is not easy? Five years may seem like a long time, but all too many attempts at major protocol transitions fail in messy and expensive ways.
Mine didn’t because I did a simple thing. I wrote libraries to handle the client side of the protocol handling, and I told all of GPSD’s client developers “Use these! Because if you write or keep your own protocol parser, it’s going to break.” Then I changed the libraries so they could handle either old or new protocol. The theory was that once my client developers linked in a library version that swung both ways, they wouldn’t have to care when the actual protocol transition happened.
That was the theory, anyway. It didn’t work perfectly, because I didn’t get the library interface design quite right the first time. Or the second. I got the interface right on about the third try, and the structure format right on the fifth. I had a few client developers yell at me, not without justification, about library transition issues. About which I can only say “Sorry. My fault.” The thing is, it could have gone much, much worse – and it usually does. Comparatively speaking I’m actually really good at this – most end-users never saw a service disruption.
What all this effort bought us, functionally, is that handling new navigation sensors in GPSD and its clients is now pretty easy. The immediate gain is support for the Marine AIS system – and if you’re wondering about the real-world impact of that, GPSD had a role in the remediation of the Deepwater Horizon disaster. We’ll probably do aircraft transponders next. Gradually GPSD is becoming the handler for every kind of sensor that tells a computer where it is and where all the GPS-equipped ships and planes around it are. In the not very distant future GPSD is likely to handle communications from GPS-equipped automobiles, too.
With 3.0, we reach the point where I expect GPSD’s protocol and the library interface to be long-term stable. There are still a few client applications that haven’t caught up – notably Firefox, which last I heard was still using a roll-your-own parser rather than my C client library. But there’s only so much I can do, really; on the whole, the transition has gone as well as could have been expected.
Most of the people who rely on GPSD will never know it’s there. It’s not a user-facing application that people actually see, it’s plumbing that the programs they do see relies on. Like physical plumbing, it’s unglamorous and out of sight and essential. I’m OK with that. There’s a quiet kind of satisfaction – not really new to me, since some of my other code is even more ubiquitous – to knowing that the world rests on your software, even if most people will never understand how.