Discussion about Cancel-Lock support

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> It may be the right moment to do the most appropriate thing as for
> configuration files.  We currently have only 1 file (inn.conf) that uses
> the internal new parser.  All the other files have various different
> parsers.

> For the new secrets.conf file, we can:
> - either directly use YAML for it, and then plan on migrating other
>   configuration files to YAML, including inn.conf;
> - or make the parser generic for several files, and then re-use it for new
>  config files.  It normally suits our needs.

I think the long-term goal, if we adopted YAML, would be to provide a YAML
version of all of the config files (with schema checking, which would be
lovely), and then provide some sort of conversion from the old format to
the new format.

Personally, I'd be happy to never have to write cryptic configuration lke:

news.uu.net/uunet\
       :*,!junk,!control,!control.*/!foo\
       :Tm:innfeed!

again and instead be able to write something like:

peers:
  news.uu.net:
    groups: "*,!junk,!control,!control.*"
    pathalias: uunet
    distributions: !foo
    innfeed: true

This is the kind of disruptive change that tends to irritate people who
have used INN for decades, though.  We could of course continue to support
both the old and new format indefinitely, but that doesn't seem great in
terms of code complexity.  I think the question is whether having a
cleaner config syntax with more human-readable options and schema checking
is enough of an advantage over, say, the current cryptic newsfeeds syntax
to be worth introducing a whole new config syntax after all this time.

Of course, stuff like newsfeeds could be way down the list and we could do
the other files that are already closer to YAML first, but I think
newsfeeds is where the largest advantage is.

(If we did something like this, it also opens the interesting possibility
of rethinking how configuration is broken up between files.  It's pretty
irritating right now to have to modify three different files with entirely
different syntax to add a new peer, and we could fix that.  That was part
of my original thought process in writing the new config parser, but then
I never followed through.)

It's a huge project, though.

> As far as I see, inn.conf has already a YAML-like syntax except for
> vectors.  We still haven't used group tags, and I doubt people use
> several parameters in the same line separated with semicolons.
> Therefore switching it to YAML should not be too much difficult unless
> of course we do at the same time a deeper refactoring and urbanization
> of all the configuration variables present in inn.conf, and that's more
> challenging.

Right.  Yeah, the "new" parser (if you can call anything that old new) has
a somewhat YAML-like syntax already.

> The drawbacks I would see for YAML is that we add a library dependency to
> libyaml, hoping it is available in all the platforms we support (libyaml
> seems more wide-spread than libfyaml).

Yes, this is a potentially serious drawback for folks who are building INN
themselves on platforms other than Linux.

> And naturally that it would make the current inn.conf parser useless
> after migrated to YAML. Which is a loss of a great deal of hard work.

Oh, don't worry about that, it was mostly my work and I don't care.  :)
It was a good learning experience for me: I learned that I shouldn't write
my own configuration parser and instead use some standard language!

> And personally I like its way to write lists ([a b c]) more than YAML
> does (multi-lines).

Little known fact: [a, b, c] is also valid YAML!

This is the blessing and the curse of YAML; the language is absurdly huge
and there are multiple ways to do things.  But, for example, valid JSON is
also valid YAML.

All of the following are equivalent in YAML:

foo:
  bar:
    - a
    - b
    - c

foo:
  bar: [a, b, c]

foo: {bar: [a, b, c]}

"foo": {"bar": ["a", "b", "c"]}

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.