Gary E. Miller <g...@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. Agreed. > 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 ntpq queries. 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>
Description: PGP signature
_______________________________________________ devel mailing list email@example.com http://lists.ntpsec.org/mailman/listinfo/devel