Danny Milosavljevic <dannym@scratchpost.org> writes:

>> [expose guix via dbus]
>
> You should keep in mind for this approach: impedance mismatch, slowness,
> different semantics, protocol versioning, and bugs in dbus (the latter
> of which I also regularily experience in guix--dbus bus hangs etc).
>
> The advantages you listed of better and easier privilege checking are
> valid, though.
>
> (In addition, I don't want a hard dependency to gtk+ in the guix package manager.
> But that can be avoided in other ways, too).

To add on top of what Danny said, I have had experience in writing GUI
over D-Bus with Nyxt: up to version 1.5 (when it was called Next), we
used to have a C server that would communicate over D-Bus to the Common
Lisp client.

We faced many issues.

- Performance was OK but could be critically bad on low-end hardware.

- Code is cumbersome to write (well, it's C :p), but maybe it's less of
  a problem if the server is Guix.

- Extensibility takes a huge toll because any modification to the server
  means the  client must be updated and vice-versa.

- What did it for us was input support: we had to encode and decode
  input events and share them over D-Bus.  This was very brittle, had
  tons of bugs and killed input method support.  I don't think it's
  doable to be honest.

When it comes to Guix, if the server does not deal with keybindings and
if the UI responsiveness only depends on the client (meaning that no
user input result depends on a result returned by the server), then I
suppose that D-Bus could work.  But I would go for GI first before going
down this road.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/