[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] ✘INCOMPATIBLE API change -- add gnssid:svid

From: Michael J. Tubby B.Sc. MIET
Subject: Re: [gpsd-dev] ✘INCOMPATIBLE API change -- add gnssid:svid
Date: Thu, 20 Sep 2018 21:05:18 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

If we're doing a major version number bump, have we sorted out the differences in the GPSD version number and the JSON API version number issues that I reported about 7-8 months ago?

From recollection there was confusion between which version number was being placed where and this meant that a program could not be compiled against an API version (for example in C with #defines for the API major/minor number) and check the version of the API in the JSON library.

The issue here is that we need to be able to:

    1. check compiled code against stated versions in (a) the API headers for the language and (b) the version info in the API messages

    2. check the version of GPSD on the other side of the API

Hence, the API needs to pass two distinct sets of version info:

    1. API version (enumerated value)
    2. GPSD version number sourcing the API

I've been out of the loop for a while so not sure if this has been sorted.... if not then pelase can we wort it while doing a major API bump?



On 9/20/2018 8:49 PM, Eric S. Raymond wrote:
Gary E. Miller <address@hidden>:
Yo All!

INCOMPATIBLE API CHANGE!  The JSON is upwardly compatible, but not the

satellite_t got bigger.  It now has gnssid and svid fields for each

The GREIS, NMEA 0183 and u-blox drivers fill in these new fields.

If valid, the new fields are included in the SKY JSON.  The client
library decodes them too.

Why?  PRN has become a mess.  No two GPS encode multiple GNSS into
the PRN the same way.  Just NMEA 0183 does it four different ways.

gpsd had the gnssid:svid data from GREIS, NMEA 0183 and NMEA, but
was trying, and failing, to mash it consistently into the PRN field.

No way the user could tell which PRN belongs to which constellation.

cgps and xgps use the new fields to show the user which constellations
different satellites belong to.

Now, at least with those three drivers, the user can trivially see
which constellation a satelltie belongs to.

Please go test.
An incompatible API change will require a major version number bump.
Also, see this list in TODO:

** Things to do when we can break compatibility **

In gps_data_t make device subtype longer. 128 chars long sounds good.

In gps_data_t, save PPS precision; this will require creating a pps struct.

In gps_fix_t, maybe change time away from float to timespec?

Add MMSI sequence number fields to AIS type 7.

I tried to make these breaks as infrequent as possible; ditro builders
don't like them.  So if we're going to have one now let's clear that
queu - either implement these changes or downcheck them.


Michael J Tubby B.Sc MIET / Technical Director / +44 (0)7973 225144

Thorcom Systems Ltd
Office: +44 (0)1905 756 700 / Fax: +44 (0)1905 755 777
Unit 4, 96B Blackpole Trading Estate West, Worcester, WR3 8TJ Registered in England & Wales 2704696 / VAT number GB 487 9256 81

reply via email to

[Prev in Thread] Current Thread [Next in Thread]