[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFH: Add prosody service
Re: RFH: Add prosody service
Fri, 02 Dec 2016 12:19:44 +0100
mu4e 0.9.16; emacs 25.1.1
>> 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
> How does that sound?
That's also what I did here:
- Re: RFH: Add prosody service,
Clément Lassieur <=