Request for design critique - configuration directories

[Gary E. Miller]

Yo Eric!

On Fri, 24 Mar 2017 17:06:08 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> > 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.

OK, so for the ake sake of argument, let's take changing the parser
off the table.  I don't really believe that, but not a problem I want
to pursue either.  That still leave a multitude of suggested alternatives
to your suffix solution which no one likes.

So, what about Achim's suggestion?  How about two directories?
	/etc/ntpd.d
	/etc/refclock.d


> this project - issue a ukase in my tech lead capacity.  We will *not*
> -- repeat *not* -- change the configuration syntax in a
> backwards-incompatible way.

Nor have I, or would I suggest otherwise.  Nor, AFAIK, has anyone
else suggest such.  You need not keep bringing up the same old straw men.

> 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've written a lot of parsers, I don't see anything difficult in there,
but I also see no win in replacing it soon.  So, since no one but you
has brought up rplacing the Bison, and you don't like it, we can drop it.

> > 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.

And yet they server precisely the same function as your filename suffixes
and are in common usage by many projects, unlike your filename suffixes.

I'm happy to junk my proposal if you are happy to junk yours.  I just
want a solution we can agree on, I'm not tied to any particular
solution.

> > 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?

Actually, that is only a tinyo change from your significant prefixes.
You specifically said files loaded in numerical order.  In short, the
suffix.

Once again, I am not wedded to any solution, but yours uses suffixes 
and prefixes, where mine uses only prefixs.  Yours has no precedent
you can cite, but mine has precedent in Apache, etc.

> You have just contradicted your own
> previous objection without quite noticing that you did so.

Simplification is not contradiction.  We can agree simplification is
good?

> 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.

As we all are.  Better to be guided by the past than repeat the
mistakes of the past.

> That's OK; nobody gets to be good at everything, not even veterans as
> grizzled as you or me. 

Yup, and when everyone with an opinion dislikes your suffixes maybe
we need to work on this some more.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170324/8f8a1afc/attachment.bin>