Proposal - drop the GPSD JSON driver

Gary E. Miller gem at
Thu Oct 20 18:52:07 UTC 2016

Yo Eric!

On Thu, 20 Oct 2016 07:11:20 -0400
"Eric S. Raymond" <esr at> wrote:

> Gary E. Miller <gem at>:
> > Oh, please not!  That is one of the big problems in the existing
> > driver. Way too compiler, CPU and OS dependent.  Plus not
> > extensible.  The exsting C struct has been nothing but problems.
> > Maybe you don't buy into JSON, but the C struct is a non-starter.  
> Way too compiler, CPU and OS dependent?
> Dependent on lots of things, but important variables (endianness,
> word length, CPU, OS) are coupled on either side because the sending
> and receiving processes are running in the same memory space on the
> same hardware.

You would think so, but years of expericne with gpsd and ntpd show
otherwise.  This problem rears its ugly head several times a year.

> Plus not extensible?
> As Hal points out, if you version-number the struct properly you can
> add fields at the end ad libitum.

IFF you do it right, AND chose a transport that can handle varying
lengths.  Traditional SHM can not do that.  The current NTP SHM can
not do that.

But that still makes it a PITA to debug.  Just look at your recent
experience with pyntpq.  You realized how much easier the ascii
query was to write than the binary one.  QED

> The existing C struct has been nothing but problems?  OK, list them
> for me. I'm not seeing it.

See my recent message to Hal, I stopped at 6, but coulda gone on...

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the devel mailing list