ntpq: cruft/doc

[Hal Murray]

esr at thyrsus.com said:
> 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. 

Ah.  Sorry.  A chunk of context got lost in this discussion.

You are talking about the general case.  I'm talking about the case where I 
know the data 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'm not sure.  Probably ease of understanding and/or maintaining.  (You can 
change the gpsd end if that helps.)

I think it's simple to write/send stuff encoded in JSON.  I don't know how to 
do the read/recv side.

Is there a good library/package to do the parsing?  Do we want to add another 
library to the list of requirements?


One of the things that's missing by just saying "JSON" and expecting all your 
troubles to be over is a layer of type checking.  I hate discovering at run 
time something that should have been detected by the tool chain.

For the case of a simple struct, I'd expect the sending side would be one line per field.  (with probably another line each for start and finish)  Can the recv side be as simple?  I'm expecting each line to be a subroutine call with a subr for each data type.  (int, float, text, bool...)

Is there a tool that turns a struct into the appropriate set of calls?


What are the rules for JSON?  Is the order of fields part of the specs?  Could I do the recv with a readline and a big sscanf?


-- 
These are my opinions.  I hate spam.