Hey Ludo,

On Thu, Apr 20 2017, Ludovic Courtès wrote:
> There must be some sort of a mapping between service types and
> configuration types, indeed, but I’m not sure how to achieve it.
>
> One solution would be to have all the <foo-configuration> records
> inherit (in the OO sense) from <service>, or something along these
> lines.

This was my first thought. I couldn't see how to do OO-style inheritance
with the SRFI-9 API, though. I'm not very experienced with Guile (or
scheme generally), so I might do some more reading about that.

One nice thing about this approach is that now a "service type" is a
scheme record-type, and a "service" is a particular instance of that
record-type, which feels slightly simpler/cleaner to me.

> Or we could make <service-type> “struct vtables” and then make
> <foo-configuration> instances of those vtables (info "(guile) Vtables").
> I’d rather avoid using those interfaces, though (currently the only
> record API we use is SRFI-9.)

I don't know what this means. I had a quick scan of the documentation,
but I'll have to read it in more detail later.

> Or we could have a ‘define-service’ macro that defines both the
> <service-type> and the <foo-configuration>, and defines a ‘foo-service’
> macro equivalent to (service foo-service-type (foo-configuration …)).
>
>   (define-service-type openssh-service-type
>     openssh-service
>     (extensions …)
>     (configuration
>       (port openssh-service-port (default 22))
>       (use-pam? openssh-service-use-pam? (default #t))))
>
> and then:
>
>    (operating-system
>      ;; …
>      (services (cons (openssh-service (port 2222)) %base-services)))

I also thought about this, but I was concerned about things like
dovecot-service, where there are two configuration objects. I wouldn't
want to force us to duplicate code, and create two different service
types, if we wanted services like that in future.

Although, maybe we would actually rather enforce a "one configuration
type per service type" rule, for the sake of modifying services? It's
hard to modify a service if you can't be sure of what the type of the
configuration will be.

Do you have a preference for what approach to use? If we use a macro to
generate things then we retain the same flexibility as the current
approach which removing a bunch of boilerplate, but I'm not sure I have
the best view of the trade-offs involved.

> I’m not sure what you mean.  Is it something like what ‘simple-service’
> does?

I meant something more like what I did with exim-service-type, where I
extend a service just to ensure its presence, then I had to document
you have to have a mail-aliases-service-type in order to use exim. With
a default configuration the mail-aliases-service-type could be
automatically instantiated if it doesn't exist.

I don't think that's a good idea, though.

Carlo