From: "Clément Lassieur" <clement@lassieur.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: RFH: Add prosody service
Date: Fri, 02 Dec 2016 12:19:44 +0100 [thread overview]
Message-ID: <87y3zybmsv.fsf@lassieur.org> (raw)
In-Reply-To: <87polfl3np.fsf@gnu.org>
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
next prev parent reply other threads:[~2016-12-02 11:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-26 17:15 RFH: Add prosody service Clément Lassieur
2016-11-26 17:20 ` [PATCH] gnu: " Clément Lassieur
2016-11-26 23:41 ` Leo Famulari
2016-11-27 10:04 ` Clément Lassieur
2016-11-26 17:20 ` Clément Lassieur
2016-11-26 21:28 ` Clément Lassieur
2016-11-26 21:30 ` Clément Lassieur
2016-11-28 19:54 ` RFH: " Hartmut Goebel
2016-11-28 21:01 ` Ludovic Courtès
2016-12-02 11:19 ` Clément Lassieur [this message]
2016-12-04 21:11 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y3zybmsv.fsf@lassieur.org \
--to=clement@lassieur.org \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).