guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFH: Add prosody service


From: Ludovic Courtès
Subject: Re: RFH: Add prosody service
Date: Sun, 04 Dec 2016 22:11:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hello Clément,

Clément Lassieur <address@hidden> skribis:

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

Sounds good.

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

No, though maybe the reference implementation just works.  Alternate,
SRFI-35 and (rnrs records), both available in Guile, support
inheritance.

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

What you did looks good.  Whether proper inheritance should be prefer
over the purely syntactic approach you took is something I can’t answer;
I guess it depends on the semantics and expected use of those data
structures.

So if it sounds good to you, we can certainly start with the patch you
have (minus duplication with (gnu services configuration).)

WDYT?

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

Perfect.  :-)

Sorry for the delay, I admit I got lost in the discussion, my bad!

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]