e...@thyrsus.com said:
> An argument for "json", maybe. But not a really compelling one, because
> GPSD defined the protocol and anything else emitting it would probably be
> emulating GPSD deliberately.
I think I prefer JSON for the same reason I like SHM.
I think the real question is does
Clark B. Wierda :
> IIRC, GPSD NG uses JSON over a socket. Is this restricted to GPSD, or is
> the JSON general enough to be used by any similar source?
It's general enough to be used by any similar source. While that wasn't one
of my design objectives, it's almost implied by
On Mon, Jun 27, 2016 at 2:49 AM, Gary E. Miller wrote:
>
> Since you opened the door...
>
> > |shm| T | Shared Memory Driver
> > |gpsd | T | GPSD NG client protocol
>
> I think that leads to confusion since they both, at least for now,
> come from gpsd.
On Mon, Jun 27, 2016 at 12:21 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
> The new refclock directive is implemented and documented. This has
> had some large consequences.
>
>
Great!
I'll echo Hal on the desirability to be less specific when we can.
I think we
Yo Eric!
On Mon, 27 Jun 2016 05:16:15 -0400
"Eric S. Raymond" wrote:
> > Maybe: gpsd_shm, and gpsd_json. Or: shm and json.
> There is in theory a better case for calling "gpsd"
> something else, but in practice I think JSON is sufficiently flexible
> that we'll never have a
Eric S. Raymond writes:
> Which reminds me: an addition I'm considering is adding "offset" as a
> synonym for time1 or time2, whichever one usually sets an offset for
> time reported from the unit.
The documentation is quite unclear on this and I'm not sure I'd trust
each driver to do exactly the
Yo Eric!
On Mon, 27 Jun 2016 00:21:45 -0400
"Eric S. Raymond" <e...@thyrsus.com> wrote:
> The new refclock directive is implemented and documented.
Cool.
> There will be a *limited* open period for bikeshedding about the
> driver names.
Since you opened the d