Re: The new refclock directive is implemented and documented

2016-06-27 Thread Hal Murray
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

Re: The new refclock directive is implemented and documented

2016-06-27 Thread Eric S. Raymond
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

Re: The new refclock directive is implemented and documented

2016-06-27 Thread Clark B. Wierda
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.

Re: The new refclock directive is implemented and documented

2016-06-27 Thread Clark B. Wierda
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

Re: The new refclock directive is implemented and documented

2016-06-27 Thread Gary E. Miller
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

Re: The new refclock directive is implemented and documented

2016-06-27 Thread Achim Gratz
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

Re: The new refclock directive is implemented and documented

2016-06-27 Thread Gary E. Miller
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