NTS client configuration support has landed

[Eric S. Raymond]

Gary E. Miller via devel <devel at ntpsec.org>:
> > If there's a good semantic reason to have a separate nts statement, I
> > can do that.
> 
> The options for the 'nts' and 'server' statements in the config file
> will be different.  Trying to merge them will confuse everyone.

Heh.  The "confuse" ship has long since sailed, Gary.  The server,
pool, and refclock declarations are handled by the same portion of the
grammar - the only reason they look distinct is that I created
refclock as a synonym for "server" to make the mess a bit
more readable.  

In fact grammatically they all take the same options - it's just that
the config builder selectively ignores various option subsets
depending on the entry type.  It's not really a very well constructed
grammar; makes for poor error messages.

To "deconfuse" the situation I'd have to tear down the grammar and redesign
it in a way that wouldn't be backwards-compatible. Crash landing.

> Right now, server looks like this:
> 
> server address [key key] [burst] [iburst] [version version]
>        [minpoll minpoll] [maxpoll maxpoll]
> 
> nts looks like this (not well decided or documented yet):
> 
> nts address [[ask address]|[require address]] [noval]] [burst] [iburst]
>        [prefer] [minpoll minpoll] [maxpoll maxpoll]

OK, it wasn't clear before that the new "nts" declaration was supposed to
*entirely replace* a server declaration rather than attaching nts options
to an existing entry.  Next time do a better job of spec-writing, please!

I therefore withdraw my DRY objection.  That is reasonable and very close to
what I have actually implemented. In fact the only difference is
that what you'd spell "nts <hostname>" I spell "server <hostname> nts"
Actually "nts" could occur anywhere in the option list.

The remaining design question is a subtle one: in what natural kind
are "server", "pool", and "refclock" alternatives?  Is "nts" another
alternative in that natural kind, or is it a property of instances of
one of the existing request alternatives?

My design goes with a user story in which "server", "pool", and "refclock"
are alternatives in the natural kind "time source requests", and "nts" is a
property that may be had by instances of the request alternatives "server"
and maybe "pool" (but not "refclock").

What is the natural kind in which "nts" is an alternative to "server",
"pool", and "refclock"?  If there is such a kind, how does that square
with the possibility that "nts" may become a property of pool request
instances?

Yes, I actually care about this kind of language consistency, and not
because I'm an irremediable pedant.  (Actually I *am* an irremediable
pedant, but that's not important right now.)  Being careful about this
sort of detail can make all the difference between a DSL that is
handy to use and easily retained, versus one that...*isn't*.

So: if you want me to make "nts" a declaration of its own, tell me
the user story in which that choice makes sense.

> I suspect some more options will be needed for the nts.

When you specify them, I'll implement them. This part is easy.
-- 
		<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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190201/8aaeeb8c/attachment-0001.bin>