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

[Vojtěch Trefný]

On 9/6/19 4:50 PM, Simon McVittie wrote:
> 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.

The DBus API is stable, we actually have some users that use the DBus
API directly, without using the library (actually it is possible that we
have more users that use the API directly), so we definitely don't plan
to do non-backward compatible changes to it.

> 
>     smcv
> _______________________________________________
> devkit-devel mailing list
> devkit-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/devkit-devel
>