From: Carlo Zancanaro <carlo@zancanaro.id.au>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Services can now have a default value
Date: Thu, 20 Apr 2017 20:19:18 +1000 [thread overview]
Message-ID: <874lxjnzyx.fsf@zancanaro.id.au> (raw)
In-Reply-To: <87bmrr4ghh.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2017-04-20 10:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-15 22:51 Services can now have a default value Ludovic Courtès
2017-04-15 23:11 ` ng0
2017-04-17 11:56 ` Ricardo Wurmus
2017-04-19 23:22 ` ng0
2017-04-20 8:53 ` Ricardo Wurmus
2017-04-20 9:09 ` ng0
2017-04-23 10:23 ` Ricardo Wurmus
2017-04-17 11:58 ` Ricardo Wurmus
2017-04-19 14:42 ` Carlo Zancanaro
2017-04-19 15:18 ` ng0
2017-04-19 21:20 ` Ludovic Courtès
[not found] ` <8737d32abz.fsf@zancanaro.id.au>
2017-04-20 8:42 ` Ludovic Courtès
2017-04-20 10:19 ` Carlo Zancanaro [this message]
2017-04-21 22:04 ` Ludovic Courtès
2017-04-21 23:41 ` Carlo Zancanaro
2017-04-22 0:46 ` We need an RFC procedure [Re: Services can now have a default value] ng0
2017-04-22 7:12 ` Ricardo Wurmus
2017-04-22 10:08 ` ng0
2017-04-22 22:55 ` Ludovic Courtès
2017-04-23 10:13 ` Ricardo Wurmus
2017-04-23 12:02 ` ng0
2017-04-27 13:29 ` Ludovic Courtès
2017-04-27 16:37 ` Petter
2017-05-02 12:42 ` Ludovic Courtès
2017-05-22 21:23 ` Ricardo Wurmus
2017-05-22 22:45 ` Leo Famulari
2017-04-23 11:52 ` ng0
2017-05-13 10:39 ` Services can now have a default value Carlo Zancanaro
2017-05-13 22:53 ` Carlo Zancanaro
2017-05-15 12:48 ` Ludovic Courtès
2017-04-22 14:46 ` Christopher Allan Webber
2017-04-22 14:59 ` Jan Nieuwenhuizen
2017-04-22 22:57 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874lxjnzyx.fsf@zancanaro.id.au \
--to=carlo@zancanaro.id.au \
--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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.