Proposal - drop the GPSD JSON driver

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> It has a different type of noise.  There is no "ready" signal on SHM so the 
> driver polls and the timing on that is just the luck of when ntpd was started.

Same thing with JSON.  The client can't predict when JSON will come up the wire.

> I'm missing the big picture.  The JSON driver was written because I (and 
> probably others) thought you thought that JSON was the right way to talk to 
> gpsd.  Was that wrong and/or did anything change?

That's complicated.

Originally GPSD JSON wasn't really supposed to be an externally
exposed protocol at all.  GPSD ships both C and Python libraries to
avoid this; I wanted control of both ends so the protocol should
change if it needed to.

Nowadays, if only because there are language bindings GPSD doesn't
ship, I accept that other people are going to pull JSON off the wire
and decode it.  JSON reflects one set of priorties: extensibility of
the protocol and eyeball-friendless are more important than minimizing
latency or jitter in most cases.  GPSD clients are not in general very
sensitive to those - or, to put it differently, their sensitivity
tends to be closer to human scale (0.1sec and up) than machine scale.

NTP is a very different case.  Minimizing jitter in the delivery chain
is all-important, extensibility and eyeball-friendliness matter barely
at all.  The overhead of formatting the JSON at one end and decoding
at the other should be avoided if it can be.

You and others modeled my thought processes incorrectly.  I left a clue
to what I was actually thinking in that communication between GPSD and
its client libraries can actually have any of three transports - JSON,
DBUS, or shared memory.  I put in the shared-memory transport specifically
for use by real-time embedded systems.

>From my point of view, the JSON driver in ntpd is a cute stunt that doesn't
really fit the context very well.  I'm mildly flattered that somebody thought
GPSD JSON was cool enough to want to play with, but the same amount of time
spent on (say) a POSIX SHM driver would have paid off better.

> Can POSIX SHM talk to non-POSIX SHM?  I assume the concepts are the same (map 
> a chunk of memory where I can see it).  Are there different name spaces?

There are.  I looked at this and wasn't able to find a way to make it work.
I'll poke at it again.

> Would pipes work better?  Or a network connection passing the same (binary) 
> info as is in the SHM segment?

As Gary just found out in connection with ntpviz, pipes pretty much
suck for this kind of work due to unpredictable buffering overhead.
I don't know whether or not that would be true of sockets.

I don't think either is going to match the performance of a shared-memory
drop.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>