ntpq: cruft/doc

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> >> CSV is readable by eye without a lot of effort.  JSON is close to 
> encrypted.
> 
> > Say *what*?  Uh, I can only conjecture that you don't have a lot of actual
> > experience with JSON. 
> 
> I admit that "encrypted" is an exaggeration, but the signal-noise is pretty 
> low.  Yes, if I'm hunting for a specific chunk of data I can find it, but 
> it's hard to get the big picture and know which chunk(s) of data I need to 
> pay attention to.

Harder than CSV, where unless someone is being conscientious (and it's
certainly not required in in RFC 4180) you get no self-descriptive
clues at *all*?  Er...no.

> I admit that I haven't worked much with JSON.  Sure, it's probably the right 
> thing for complicated data structures.  But I'm mostly interested in simple 
> tabular data where CSV works well.
> 
> If you want to convince me that JSON is great, rewrite the gpsd refclock to 
> be a shining example.

I can't figure out what you're recommending here, and I want to
because I believe in taking you seriously even when I think you've
just said something actually *silly* for the first time in recorded
history.  Cleaning up the parsing code in the driver? Changing the way
it's generated in gpsd?  What's the axis of "better" here?

I actually think GPSD protocol *is* a shining example.  I struggled
with that design problem for three years, trying to come up with
a wire protocol with the right readability and extensibility properties.
Extensibility is a huge deal here because given the problem domain you
never know when you might have to add another object type on the wire,
like AIS or PPS.

"I can just use JSON" was like a lightning bolt when I finally got it.
There's nothing better for structured, self-describing datagrams.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>