Request for design critique - configuration directories

Gary E. Miller gem at rellim.com
Fri Mar 24 19:14:08 UTC 2017


Yo Eric!

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

> In the abstract, this would be equivalent.  There are two problems
> with it:
> 
> 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.

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.

> 2. The objective of this new feature is to make life easier for
> packagers to write scripts that assemble snippets into working
> configs. For this purpose, experience with (e.g.) Apache 2 seems to
> show that shuffling around files with renames is easier and less
> error prone that concatenating configuration content into product
> files.

Once again your are conflating the same two issues.  No one is arguing
against the Apache model.  Except you, when you propose file extensions
which Apache does not use.


> You may not be fan of "encoding much in filenames", and I'm not
> attached to the technique myself, but under these constraints I'm not
> seeing a better alternative.  Perhaps you can dream up one?

No need to dream, already in my previsou proposal, which is merely
my understadning of a currently very common technique.

> > > 5. The "other files are skipped" is a convenience for
> > > configurators, which can use file renames to enable and disable
> > > configuration snippets while leaving the file conyent of snippets
> > > untouched.  
> > 
> > Hmm, without the extentions this is harder.  Maybe the all end in 
> > .ntp, or must start with a number?  Then README gets skipped.  
> 
> I don't understand this remark.  Under the present rules README
> is already skipped.

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.

So far there is zero support here for your suffix suggestion.  Nothing but
support for the Apache like part of your suggestion.  

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/2233f14d/attachment.bin>


More information about the devel mailing list