Re: RFH: Add prosody service

[Clément Lassieur]

Hi Ludovic,

>> 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>?

That wouldn't solve problem B.

>> 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?

That's kind of what I did here:
http://lists.gnu.org/archive/html/guix-devel/2016-11/msg01075.html

The macro 'define-all-configurations' defines two default values: one
for the global context (def) and one for the virtual-host context
('disabled).

(The macro I did also changes the doc and the type, depending on whether
it's a virtualhost or not.)

> 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.

Which is not implemented by Guile, is it?

So is what I did desirable?  Or maybe should we wait until we have
something similar to SRFI-99, and use opaque-prosody-configuration only?

>> 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's also what I did here:
http://lists.gnu.org/archive/html/guix-devel/2016-11/msg01075.html

-- 
Clément