Hello, Carlo Zancanaro <ca...@zancanaro.id.au> skribis:
> 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. SRFI-99 supports inheritance, though there’s currently no SRFI-99 module in Guile proper: https://srfi.schemers.org/srfi-99/srfi-99.html Oh and there’s also R6RS records, SRFI-35… no shortage of record APIs! :-) >> 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. Right, I would prefer one type per service. I didn’t know dovecot was different. > 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. A ‘define-service-type’ macro or similar could generate either code the current framework (with <service-type> and <service> and <foo-configuration>) or for SRFI-99-style records if we later to go that route. So I think we should start by designing this macro. How does that sound? >> 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. Oh right. Well I don’t know, perhaps in some cases it might make sense to automatically instantiate things depended on. The advantage is that as a user of the service (exim for instance) you don’t have to be aware of the services it expects (improves separation of concern). So you could blissfully write just: (cons (service mediagoblin-service-type) %base-services) and behind the scenes it would add an nginx instance, an mcron instance with a couple of jobs, a rottlog instance, and so on. WDYT? Thanks, Ludo’.
