The request side of NTS is working

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> > I'll study authinfo and get back to you, probably tomorrow.
> 
> authinfo is a bad example.  ntpq has its own copy of that list.

ntpq has its own copy of the lists for almost *all* the standard ntpq displays.
There are only three exceptions; those lists are in ntp_control.c

> I thought there was at least one command that didn't need it's own list, but I 
> can't find an example.

Three. The default system variables, the default peer variables, and the
default clock variables. That's as opposed to nine display groups defined
in ntpq.py.

> Beware, you may get sucked in.  The swamp is pretty deep, but it's the sort of 
> problem you are good at.  The fundamental problem is that there are 3 tables 
> that have to be kept in sync.
>   There is a text "table" of #defines to assign sequential numbers to handles,
>   a table of strings for mapping strings to handles,
>   and a final select on handle to format the result.
> 
> You will see when you get there if you don't remember.  I'm slightly surprised 
> you haven't cleaned it up already.

Never seemed urgent before.  Now, I want to get the code to where adding your
NTS counters has a lot less friction and ad-hockery about it. I figure this
is my next day or so of work.

You have identified one issue - the tables in ntp-Control.c are a mess.  Here's
what I said about that in a comment on issue #539:

    I can easily reduce the number of tables from 6 to 3. The cost of the
    only non-complicated way to do it is that the order in which variables
    in the default displayed set are printed would change - the second
    table in each pair exists to define the order of that traversal.

    I don't think this is a real problem. But you're the one with ops
    experience, not me. If you confirm that it isn't, I'll make the
    change.

Now I can add this: at least one of the orderings wired into
ntp_control.c is there to preserve exact interface compatibility with the
extinct species "fuzzball"!  In 2019 this seems silly.

The other is the fact that policy (the assignment of which variables
are in which display groups) is split between two places, ntp_control.c
and ntpq.  This is wrong and unstable and I *will* fix it now that I've
actually noticed it.

ntpq.py has comments in it that read

# FIXME: This table should move to ntpd
#          so the answers track when ntpd is updated

I think that - moving policy into ntp_control.c - is the wrong direction.
Mechanism belongs in ntp_control.c; policy should migrate outward to ntpq
where it's easy to change without perturbing the core code.  (That will
also reduce C LOC in favor of increasing Python LOC, which is always good
for maintainability.)

What I will do, unless you tell me there's something really important about
those three wired-in order tables in ntp_control.c, is move them to ntpq.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.