On the format of config files

Olaf Titz olaf at bigred.inka.de
Mon Apr 10 10:01:07 UTC 2000


[CC to inn-workers]
> > If done right... (why it's not done right in INN belongs on another
> > list).
>
> I'd be curious on your comments here.

I think the labeling of groups is done backwards in
{readers,storage}.conf. The reason is that the label key is
supposed to be a _key_, at least this is what I read that syntax like.
Cf. BIND:
zone "127.IN-ADDR.ARPA" {
        type master; file "named.local";
};
i.e. the label on the group is the identifier.
See also innfeed.conf, where the group name identifies the peer.

storage.conf has this:
method METHOD {
  newsgroups: PATTERN
  class: CLASS
}
where METHOD does repeat and it is not clear why the method should be
a distinction criterion. The way I would have written this is
class CLASS {
  newsgroups: PATTERN
  method: METHOD
}
because CLASS is an identifier-like thing (in this case, it doesn't
_have_ to be unique, but it looks just more logical to me).


About readers.conf, it's not so clear what is wrong there, but the
access and auth groups and the links between them was confusing enough
that I needed perhaps an hour to understand it when it was first
introduced. Maybe just the docs should be clearer.

A deficiency in the current scheme:
auth GROUP {
  hosts: HOSTS
}
access GROUP {
  newsgroups: PATTERN
}
is at least that it is not clear which GROUP references which. The
following looks equivalent but makes clear that there is a pointer,
and in which direction it goes:

auth GROUP {
  hosts: HOSTS
}
access {
  auth: GROUP
  newsgroups: PATTERN
}


Btw. the nested grouping in incoming.conf could be avoided by using
group labels as pointers where appropriate. Rewriting the example from
the man page:

global {
  max-connections: 5
}
peer vixie {
  hostname: gw.home.vix.com
  max-connections: 10
}
group fast-sites {
  max-connections: 15
}
peer bb.home.vix.com {
  hostname: bb.home.vix.com
  group: fast-sites
}

so we do actually use the labels. I'm not sure whether the current,
nested syntax is actually easier to understand, and I think the
parsing is roughly equivalent (if done with yacc), but I'd like to
avoid having one parameter in too many different contexts. Take the
XFree86 4.0 config file, where the first question always is, "in which
section does that parameter belong?" They really have missed a great
chance to completely redo their config file to make it less confusing.

Just another example: to make cycbuff.conf use this format too, I very
strongly recommend to do it like this:

cycbuff BUFNAME {
  file: FILE
  size: KBYTES
}
group GROUPNAME {
  cycbuffs: BUFNAME BUFNAME...
}

and have GROUPNAME referenced in storage.conf.

The whole idea behind all this is that sections have names, so let's
use them.

Olaf




More information about the inn-workers mailing list