Eric S. Raymond
esr at thyrsus.com
Sun Oct 16 12:43:06 UTC 2016
Gary E. Miller <gem at rellim.com>:
> > The other is the UI? Do you prefer fancy click-around GUIs, or
> > dumb/simple CLI with text output?
> I'm for a nice little text output CLI tool. Mostly for quick data
> visualization on very dummb servers. Maybe with an optional csv output
> so it can be used in a tool chain.
I'm with Gary on this one. Given a well-designed CLI tool you can write
a GUI wrapper around it without much difficulty (and Python is a particularly
good tool for this) but the reverse is not true.
About CSV, while I'm not opposed to it we have a practice guideline to
use JSON for machine-parseable output. One reason is that JSON is better
at being self-describing - the field names give you clues that CSV doesn't.
> The first thing I would do is auto scale the output. Hardly anyone
> remembers the output of 'ntpq -p' is all in milli seconds. Even less
> often is millis seconds the best range. I like how chronyc does the
> auto ranging.
> Many of the pages should be mashed up. Data is just spread out all over
> in a jumbled fashion. Recently here someone was complaining that to
> look at 'rv' data in ntpq you had to first go find out the association
> ID of a peer (with associations), even though you already had the IP or
> refclock number.
I agree, the ntpq UI is badly designed. But I don't think we can just
throw it out. My plan is to move it to Python, and factor it properly
so the grotty bits of the UI are properly separated from a querying
engine which can in principle be cleaner and more orthogonal. This
will require defining an object API in Python for the client end of
Then we will be able to use that layer to write both a better CLI tool and
(possibly) a nice GUI as well, with minimal code investment in either.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: not available
More information about the devel