udisks library use with a replacement daemon: library-only knob?

[Simon McVittie]

On Fri, 06 Sep 2019 at 09:52:56 +0200, Vojtěch Trefný wrote:
> On 9/6/19 4:56 AM, Pau Amma wrote:
> > So it
> > should be possible to use the library with a FreeBSD-specific daemon (that
> > already exists) providing the same messaging interface.
> 
> There might be some other issues with this, libudisks code is generated
> from the UDisks code using GDBus codegen so there might be some
> dependencies to the daemon. As far as I know, nobody tried to do
> something like this, but it should be possible.

If udisks is following the usual GDBus pattern, then the client-side code
(libudisks) and the service-side code (in either a library or the daemon)
would normally both be generated from the same D-Bus introspection XML
(which is D-Bus' equivalent of an IDL), so disabling the daemon shouldn't
break the client library. If that's the case, a FreeBSD reimplementation
of udisksd could also generate its D-Bus interfaces from (its own copy
of) the same XML.

Another situation in which it might make sense to be able to disable
building the daemon is if you're building the library to bundle it into
a container runtime or containerized app (for example Flatpak), and you
plan to use it to connect to a daemon that runs outside the container.
In that situation, having the daemon available inside the container
is pointless.

Of course this all assumes that the udisks D-Bus API is long-term stable
and backwards-compatible (like for example MPRIS2 and systemd, but unlike
evolution-data-server and GtkApplication). If the D-Bus API is treated
by its maintainers as a private implementation detail of libudisks and
udisksd, then using libudisks to talk to a different daemon (either a
FreeBSD reimplementation, or a udisksd outside a container) is not going
to work reliably.

    smcv