A day is coming when the application interface of GPSD will have to change in a major and incompatible way. This page explains why, and what you as a GPS-aware application writer can do to be forward- and backward-compatible when the day comes.

Why the disruption?

The design of the request/response protocol that our client libraries use to talk to the daemon is inadequate. We are nearly out of room to maneuver around the inadequacies, and fixing them will require a major break with the past.

The protocol design made sense under the cost constraints of the mid-1990s when the earliest paleolithic versions of GPSD were first written, but there are three specific problems with it that have grown more pressing as the range of GPS-using applications has widened and the daemon's command set has expaned to match:

  1. Commands are single letters, and we have about run out of letters. (This means there's no little or room left to extend the command set.)

  2. There's no way to support returning multiline responses to a client. (This is a problem for returning things like RINEX format, which we'd like to be able to do when a device can report pseudoranges.)

  3. The existing command set encourages sloppy handling of data by supporting commands that return PVT and fix-quality information in atomized partial form, without timestamps.

Client wrapper libraries like libgps seal off applications from most of the protocol level, but not all of it. In particular, the second argument of gps_query() is a protocol command string. Thus, even if the coming transition doesn't change the libgps function-call signatures in the API, client code will have to change.

Minimizing the impact

The first step to minimizing your exposure is this: Don't talk directly to GPSD. Use one of the client libraries we ship instead; we have one for C, one for Python, and there is a separately distributed Net::GPSD for Perl. By not doing the response parsing yourself, you'll avoid having huge amounts of code exposed to the protocol change.

Each set of client bindings will provide a major and minor API revision-level symbol. The final major revision of the old interface is 3; arguably it should actually 1, but we didn't have a separate count for minor revisions until this transition was into the planning stages.

Use the API level to conditionalize your client code. In the best case, all that will change is gps_query() argument strings, but we're not sure of that yet.