Re: [PATCH] improve nginx-service

[ludo@gnu.org (Ludovic Courtès)]

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> BTW: I just started typing down a simple "location" record type, and
> started to think if these record types are really the way to go for the
> configuration.
>
> In nginx AFAIK you can define many options on the server level, on the
> vhost level and per location. Additionally locations can be nested. And
> some configuration options are quite complex, e.g. "listen" [1] and
> maybe worth their own type. So we'll create a lot of code for both the
> record types and for converting them to config-file text.
>
> In the long run, we will get maintenance problems, I'm afraid, if we are
> only allow options known to us and written into the service. On each
> update we'd need to check if any option was added.

You’re right: we never want our Scheme interface to config files to
be less expressive than the original config syntax.

Yet, having a Scheme interface to config files is valuable: people don’t
have to learn a new syntax, you get compile-time checks of field names,
it’s easier to customize config represented as a Scheme object, etc.

So there’s a tension here.

So far, there’s no single approach to this problem in GuixSD.  In some
cases we don’t provide a Scheme interface at all (e.g., syslogd), which
isn’t great.  In other cases (e.g., nginx, Tor), we provide a partial
Scheme interface along with a way to augment the config file using its
native syntax.  In yet other cases (CUPS, Dovecot, added by Andy, or
libc’s NSS and PAM), services have a Scheme interface that cover 100% of
their current config space, sometimes with the added ability to provide
raw inline config.

I think this last approach is the preferred approach, but it’s also more
difficult to get right in some cases.  For instance, nginx config is not
just about key/value arguments: it has blocks, a notion of scope, etc.
So nginx config syntax and semantics is more complicated than key/value
configs such as that of Dovecot or Tor.

> So IMHO the recard types are not the way to go. We need a more flexible
> way, maybe like used for XML (see default-build.xml in
> guix/build/ant-build-system.scm), but with support for default values.

We could obviously use s-expressions for everything (they are
essentially typed XML).  However, people would get zero compile-time
checks and it would also be much harder (and less efficient) to deal
with them.

Ludo’.