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
