Re: Service refactoring

[Andy Wingo]

Hi!  Some thoughts but I am interested to see your results, your
approach sounds good.

On Tue 08 Sep 2015 12:12, address@hidden (Ludovic Courtès) writes:

> An issue is that each finalization procedure is passed more information
> than strictly needed.  Thus, any service can potentially influence any
> other service’s configuration, which makes it harder to reason about
> service composition.

Good point.

> Another problem is that it’s not really extensible: we’ll have to keep
> adding new fields to <service> every time we think of a new way a
> service needs to extend another service.  We could use an alist instead
> of those record fields, but then that would make the thing sloppy (typos
> would go undetected, etc.)

On the scale of badness, this to me is bad but not so bad.  How many of
these kinds of services will there be?  I am guessing like 6 or so (pam,
udev, dbus, polkit, file systems, dunno).  It's manageable.

If you extend services as first-class values -- is this your proposal?
-- that gets more precise, but then you have the problem of -- well
let's say that desktop.scm defines dbus-service, which is a factory
procedure.  What would elogind-service capture?  Would you have to pass
in the value of the instantiated dbus service in your (operating-system
(services _))?

> There’s also the assumption that each service that the user specifies
> maps to a dmd service, which is not always the case (D-Bus services,
> Apache modules, etc.)

Good point...

> Lastly, without making the “extends” relations explicit, it’s easy to
> end up specifying an extension that actually extends nothing.  For
> instance, you use a service that has a non-empty ‘dbus-services’ field
> but forget to use the D-Bus service; Guix has no way to tell that
> something’s missing.

This is only the case if you have an open extension set.  If the
extension set is closed, like the set of <service> fields is closed, we
can add custom logic.

> What I suggested would address these by constraining things.  What
> remains to be seen is if this can be implemented without making things
> too complex.  I’ll try to experiment with this.

Good luck :)  Looking forward to see what you come up with.

Cheers,

Andy