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 _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/devkit-devel