Future of the GPSD project
Author: Remco Treffkorn
Description: GPSd is a utility that can listen to a GPS or AIS receiver and re-publish the positional data in a simpler format.
Keywords: GPS, translator, mxmap, GIS

Future of the GPS project

This page is our roadmap for future features and releases.

## The new GPSD protocol

2.90 has shipped, and with it the redesign of GPSD's wire protocol. While this brings many benefits (including, immediately, the ability to interpret and report on the output of marine AIS receivers) it poses some significant deployment challenges as well.

Over the next few releases we're going to be preoccupied with managing the transition to the new protocol.. See that document for our tentative release schedule:

For more on specific tasks planned for upcoming releases, see our file.

## Changing hosting sites

We're presently (April 2010) hosted at berlios.de, but find that it has become extremely flaky of late (logins failing due to broken SSL certs is the most recent symptom). We plan to change sites some time in 2010.

## Changing build systems

Our build is presently autotools-based. We may move to scons in 2010. Autotools is a festering pile of hacks, and will become a serious liability if David Ludlow's Windows port actually finishes.

## Delegating DBUS support to geoclue

We're going to stop shipping DBUS notifications directly at some point. Note: This is no longer a near-term prospect, as geoclue is reported not sufficientrly stable to bear the weight.

The reason for this is GeoClue. GeoClue is an aggregator that takes geolocation-related information from provider programs, including `gpsd`, and publishes it on DBUS.

For us, DBUS support is a dusty backwater in our code. We don't track what the DBUS community is doing or expecting. Our devteam worries about version skew between GPSD's DBUS transmissions and client apps, and wouldn't have the knowledge base to fix that quickly if it happened.

The GeoClue team, on the other hand, loves DBUS and specializes in it. We think it's probably best for both projects if they take data from us and handle the DBUS publishing job for us.

## Client API cleanup

This will happen after 2.95 but before 3.0.

The client API has some historical baggage, unfortunate naming, and scar tissue in it. At some point we're going to bump the API major version number to 5 and make the following changes:

- MAXCHANNELS will increase so we can handle a GPS + GLONASS constellation. This has become a production issue because of the Geostar Geos 1M. (Done in 2.96~dev.)

- gps_open_r() will be renamed to gps_open(). The existing gps_open() will go away. (Done in 2.96~dev.)

- The 'waiting' and 'buffer' members of privdata will move into the public part of gps.h. (Done in 2.96~dev.)

- gps_set_raw_hook() will be removed. Instead, clients will simply be able to look at the packet buffer directly. (Of course, this is only recommended when the PACKET_SET flag is up.)

- gps_poll() will be renamed to gps_read(). (Done in 2.96~dev.)

- There will be a new gps_poll() entry point that will perform a nonblocking poll of the daemon, using the (now experimental) ?POLL command).

- The message 24 structure may be split into part A and B so these are in effect separate messages.

Client API users will have the API_MAJOR_VERSION symbol available to conditionalize their code so it will work with any version.

What is most likely to trigger this change is the restoration of polling as a fully-supported mode in the wire protocol (it is presently experimental and buggy and not recommended for production use). At that point, the skew between what ?POLL does and what and gps_poll() does will become severe.