guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#54986] [PATCH] gnu: mpd: Add support for socket activation.


From: Maxim Cournoyer
Subject: [bug#54986] [PATCH] gnu: mpd: Add support for socket activation.
Date: Mon, 01 May 2023 11:53:52 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Dienstag, dem 25.04.2023 um 20:33 -0400 schrieb Maxim Cournoyer:
>> Hi!
>> 
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> > * gnu/services/shepherd.scm (<shepherd-endpoint>): New record type.
>> > (shepherd-endpoint->sexp): New variable.
>> > * doc/guix.texi (Shepherd Services): Document it.
>> 
>> Like Ludovic, I'm wondering what duplicating the Shepherd endpoints
>> API in Guix buys us?  It sometimes feel a bit contrived to have to
>> work inside the service's gexp expression, but other than that, I
>> think it's good to:
>> 
>> 1. Avoid duplication.
>> 2. Keep it as internal/hidden as possible from users.
> I agree with the point about avoiding duplication, but I want users to
> be able to specify endpoints for socket activation.  This has several
> benefits: It firstly allows users to specify that they want a specific
> service to be started on demand rather than on boot, and it also allows
> them to bind to multiple endpoints, e.g. any IPv4 address, any IPv6
> address or both.  Duplicating the API here is merely a means of
> allowing users to express the above in a Guixy fashion.  It also gives
> us type-checking which a simple quote or quasiquote doesn't.  If the
> same can be achieved by inspecting Shepherd's records and we can allow
> Guix to depend on Shepherd, that'd be fine by me. 

Instead of replicating the Shepherd API in Guix, could we use the
Shepherd API directly?  It's Scheme, and already depended on by Guix, so
the question arises.

It may not be a good idea, but I need to be refreshed on the reasons
:-).

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]