Request for design critique - configuration directories

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> "Eric S. Raymond" <esr at thyrsus.com> wrote:
> > 1. It would require a backward-incompatible change to the
> > configuration syntax and significant surgery on the parser. While it
> > is the case that I am a yacc wizard for whom this surgery would be
> > relatively easy, I firmly reject inflicting the incompatibility on
> > our users without a *much* stronger case for tolerating the breakage
> > than we now have.
> 
> I can't agree.  I can't agree on either point.
> 
> If adding a single new state variable to the yacc parser is such a pain,
> then time to get rid of the yacc stuff.  Many other projects do as I
> propose, the code to do it must be readily available.

You don't grasp the magnitude of the can of worms you are opening.
You really don't.  If you did, you'd run screaming from your own
proposal.  It's not a matter of a state variable, it's far, *far* more
complex than that.  And not only because of the way yacc works but
because of the syntax-tree intermediate representation ntpd uses and
the way it's used to propagate information to the rest of ntpd.

I'm not going to go any further with *this* thread of the conversation
until and unless you learn enough about YACC and the custom scanner
and the interior syntax-tree representation to implement MR #251 (Add
fudge option to server config) yourself.  You will, as Mark Twain once
put it about a man trying to carry a cat home by the tail, gain a
valuable education that will never grow dim or doubtful.

And as for replacing the entire parser...

I am going to now do something I've only done maybe twice before on
this project - issue a ukase in my tech lead capacity.  We will *not*
-- repeat *not* -- change the configuration syntax in a
backwards-incompatible way.  That is off the table; I will *not*
sabotage our chances of adoption by inflicting that pain on people
thinking about switching from Classic.  I am certain Mark will back
me on this.

That implies that we are not going to try to replace the Bison parser,
either.  Because thirty-five years of experience and being one of the
handful of people most expert at this particular kind of hacking tells
me that trying to implement a 100% backward compatible grammar as
complex as ntpd.conf's with a different parser engine is ... I'm just
going to say "doomed".  Utterly doomed. The edge cases will get you
*every fscking time*.

> I do not see where the incompatibility is.  I proposed that anything
> not in one of the three new sections be assummed to be in global.  And
> I proposed that all existing config statements be allowed in global.

Then your proposed section tags are literally useless. And will never
be adopted by users, because they solve no problem.  They're at best
meaningless decoration and probably misleading noise.

> Your proposal skips README because it does not have you desired suffix.
> Mine skips README becase it does not have the desired prefix.  There are
> many existing examples of using digits as the prefix.  Quite common in
> fact.  I can think of zero existing implementations uinsg a suffix like
> yours.

Significant prefixes, right.  So, what became of your dislike of
encoding things in filenames?  You have just contradicted your own
previous objection without quite noticing that you did so.

I deduce that we have wandered into an area where your design judgment
is unreliable, and what you have instead is prejudices formed by
random past experiences.

That's OK; nobody gets to be good at everything, not even veterans as
grizzled as you or me.  I will continue to rely on your judgment in
other areas where you demonstrate more insight or domain knowledge
than me.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.

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