From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] improve nginx-service Date: Sun, 06 Nov 2016 18:33:27 +0100 Message-ID: <87eg2o1pjs.fsf@gnu.org> References: <20161016143347.38d8a6f2@polymos.lepiller.eu> <874m483vap.fsf@gnu.org> <20161020143744.516a1184@polymos.lepiller.eu> <87shrlzd0w.fsf@gnu.org> <20161026214507.45445d14@lepiller.eu> <87y41aklqp.fsf@gnu.org> <20161027195949.354cae8e@lepiller.eu> <87pomhse6w.fsf@gnu.org> <87lgx0txz0.fsf@gnu.org> <87h97n1iu0.fsf@gnu.org> <20161104190129.684844b4@lepiller.eu> <20161104231253.4b52d70f@lepiller.eu> <4b44538a-ed70-aacd-4867-5267847aee42@crazy-compilers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3RK1-0002XD-Qu for guix-devel@gnu.org; Sun, 06 Nov 2016 12:33:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3RJy-0002F3-Nq for guix-devel@gnu.org; Sun, 06 Nov 2016 12:33:33 -0500 In-Reply-To: <4b44538a-ed70-aacd-4867-5267847aee42@crazy-compilers.com> (Hartmut Goebel's message of "Fri, 4 Nov 2016 23:58:01 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Hartmut Goebel Cc: guix-devel@gnu.org Hartmut Goebel 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=E2=80=99re 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=E2= =80=99t have to learn a new syntax, you get compile-time checks of field names, it=E2=80=99s easier to customize config represented as a Scheme object, etc. So there=E2=80=99s a tension here. So far, there=E2=80=99s no single approach to this problem in GuixSD. In s= ome cases we don=E2=80=99t provide a Scheme interface at all (e.g., syslogd), w= hich isn=E2=80=99t great. In other cases (e.g., nginx, Tor), we provide a parti= al 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=E2=80=99s NSS and PAM), services have a Scheme interface that cover 10= 0% 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=E2=80=99s 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=E2=80=99.