[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] improve nginx-service
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH] improve nginx-service |
Date: |
Sun, 06 Nov 2016 18:33:27 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hartmut Goebel <address@hidden> 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’.
- Re: [PATCH] improve nginx-service, (continued)
- Re: [PATCH] improve nginx-service, Tobias Geerinckx-Rice, 2016/11/06
- Re: [PATCH] improve nginx-service, Ludovic Courtès, 2016/11/06
- Re: [PATCH] improve nginx-service, Julien Lepiller, 2016/11/20
- Re: [PATCH] improve nginx-service, Hartmut Goebel, 2016/11/22
- Re: [PATCH] improve nginx-service, julien lepiller, 2016/11/23
- Re: [PATCH] improve nginx-service, Clément Lassieur, 2016/11/25
- is using eval good style in guile?(was: [PATCH] improve nginx-service), Hartmut Goebel, 2016/11/25
- Re: is using eval good style in guile?, Andy Wingo, 2016/11/25
- Re: is using eval good style in guile?, Clément Lassieur, 2016/11/26
- Re: [PATCH] improve nginx-service, Ludovic Courtès, 2016/11/27
- Re: [PATCH] improve nginx-service,
Ludovic Courtès <=