Hi! Some thoughts but I am interested to see your results, your approach sounds good.
On Tue 08 Sep 2015 12:12, l...@gnu.org (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
