[Top][All Lists]

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

Re: RFH: Add prosody service

From: Clément Lassieur
Subject: Re: RFH: Add prosody service
Date: Fri, 02 Dec 2016 12:19:44 +0100
User-agent: mu4e 0.9.16; emacs 25.1.1

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:

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

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


reply via email to

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