Re: RFH: Add prosody service

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

Hi!

Clément Lassieur <clement@lassieur.org> skribis:

> I'm actually working on the Prosody service, and I am struggling with a
> few things.  What I did works, but some configurations are probably
> missing.  I'm not sure I'm doing it the right way, so I would appreciate
> a few comments before I go further.
>
> Here is how a typical .lua Prosody configuration file looks like:
>
> -- global section --
>
> global-1 = ...
> global-2 = ...
> common-1 = ...
> common-2 = ...
> common-3 = ...
>
> -- virtualhosts section --
>
> Virtualhost domain1
>   common-1 = ...
>   common-2 = ...
>   common-3 = ...
>
> Virtualhost domain2
>   common-1 = ...
>   common-2 = ...
>   common-3 = ...
>
> Settings that are in the global section apply to all virtualhosts.
> Settings under each Virtualhost entry apply only to that virtualhost.
>
> So in Scheme, I implemented this as a prosody-configuration
> (representing the whole file), containing:
>   - global settings,
>   - common settings,
>   - a list of virtualhost-configuration.
>
> Here are my problems.
>
> A. A virtualhost-configuration has a lot in common with
>    prosody-configuration, and I don't want to repeat stuff.

What about a <prosody-global-settings> record that would have
‘global-1’…‘global-N’ fields, plus a ‘virtual-host-settings’ that would
aggregate a <prosody-virtual-host>?

> B. Common settings should have a default value in prosody-configuration,
>    and be disabled by default in the list of virtualhost-configurations.

Oh, I see.

> I found two ways to solve this:
>
> 1. One uses "eval" to transform the input of "define-configuration" into
>    a list that I can build from other lists.
>
> 2. The other uses a macro that takes define-configuration's input, plus
>    a tag (called target) describing whether it's a global, common, or
>    virtualhost specific field.  Then the macro calls
>    define-configuration many times, each time with a subset of the
>    original input, filtered with a specific tag ("global",
>    "virtualhost") plus the "common" tag.
>    (Its name is define-all-configurations.)

I think you could always write a ‘define-common-configurations’ macro on
top of ‘define-configuration’ that would let you specify two default
values: one for the global context, and one for the virtual-host
contexts.  (Thus, no need for ‘eval’: the code is generated at macro
expansion time.)

Would that work?

It would allow you to avoid repeating field definitions, but you’d end
up with two almost identical record types that are completely disjoint
(no inheritance in particular.)  This may or may not be desirable.

For record type inheritance, we’d need SRFI-99 or something equivalent.

> There's another issue: how to represent fields that we don't want to
> serialize (see problem B).  I define a macro (define-maybe) that adds to
> a field the possibility to have the value 'disabled.  But there are
> plenty of other ways to do, I could do differently, just tell me.  There
> is this thread talking about it:
> http://lists.gnu.org/archive/html/guix-devel/2016-11/msg01024.html.

Looking at (gnu services mail), you can define custom field types with
associated serializers.

So you could define a ‘maybe-string’ type, say, with an associated
serializer.

How does that sound?

That said, I’m not familiar with (gnu services configuration) yet.

Ludo’.