Bug 92080 - Optional client configuration file support
Summary: Optional client configuration file support
Status: RESOLVED MOVED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.10
Hardware: Other All
: medium normal
Assignee: D-Bus Maintainers
QA Contact: D-Bus Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-22 21:15 UTC by Ralf Habacker
Modified: 2018-10-12 21:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Add optional client configuration file support (21.09 KB, patch)
2015-09-22 21:15 UTC, Ralf Habacker
Details | Splinter Review
Display autolaunch scope on verbose print of daemon found message on windows. (1.04 KB, patch)
2015-10-04 08:39 UTC, Ralf Habacker
Details | Splinter Review
Try autolaunch:scope=*install-path by default on Windows (3.87 KB, patch)
2015-10-14 13:05 UTC, Simon McVittie
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Habacker 2015-09-22 21:15:05 UTC
Created attachment 118405 [details] [review]
Add optional client configuration file support

On Windows dbus installations comes into two flavours: 

1. standalone dbus installer or portable installation [1]
2. dbus bundled with 3rdparty applications [2]

[1] https://build.opensuse.org/package/show?project=home%3Arhabacker%3Abranches%3Awindows%3Amingw%3Awin32&package=mingw32-dbus-1-installer
[2] https://build.opensuse.org/package/show?project=windows%3Amingw%3Awin32&package=mingw32-umbrello

The standalone installers provides a session bus identified by the main 'autolaunch:' meta protocol. Every client using protocol 'autolaunch:' to connect to the session bus reaches the standalone dbus installation.

DBus bundled installation can be configured to use a standalone dbus installation or the bundled dbus instance. The latter is reached with the 'autolaunch:scope=*install-path' connection string, which is required to be configured for the daemon (dbus-1.10: <install-root>/share/dbus-1/session.conf) and all clients. 

Windows applications installed by an installer are started by a start menu entry, which does not allow to provides environment variables to setup the client connection string.

With this patch the dbus message bus library could be compiled to have a client configuration file to provide the possibility for dedicated client connection string setup at one place.
 
The client configuration file is located at <install-root>/share/dbus-1/client.conf.

BTW: The recent implementation uses expat to parse the xml file. Another solutions without the need to add an additional library dependency to libdbus would be to use a simple inline xml parser or to use a simple ini-style file parser (I remember that it has already been thought to simplify dbus file format)
Comment 1 Simon McVittie 2015-09-23 14:27:46 UTC
(In reply to Ralf Habacker from comment #0)
> DBus bundled installation can be configured to use a standalone dbus
> installation or the bundled dbus instance. The latter is reached with the
> 'autolaunch:scope=*install-path' connection string, which is required to be
> configured for the daemon (dbus-1.10:
> <install-root>/share/dbus-1/session.conf) and all clients. 

Can't you achieve this by configuring the bundled D-Bus instance's default listen and connect address appropriately?

I would prefer not to have

* find your own installation directory;
* find a config file in that directory;
* connect to an address based on that config file

if we can have

* find your own installation directory;
* connect to an address based on that directory

which I think is what autolaunch:scope=*install-path already does?

For instance, if it would help, I wouldn't object to changing the default for --with-dbus-session-bus-connect-address on Windows to "autolaunch:scope=*install-path;autolaunch", or in other words "try a bundled copy, then fall back to standalone".

> BTW: The recent implementation uses expat to parse the xml file. Another
> solutions without the need to add an additional library dependency to
> libdbus would be to use a simple inline xml parser or to use a simple
> ini-style file parser (I remember that it has already been thought to
> simplify dbus file format)

If we need any new configuration files, I would strongly prefer to share the format and code we already have for .service files, which is freedesktop.org .desktop file syntax.
Comment 2 Ralf Habacker 2015-10-02 20:09:02 UTC
(In reply to Simon McVittie from comment #1)
> which I think is what autolaunch:scope=*install-path already does?

yes, it is required to be set on the server *and* client side to have a bundled dbus instance. 

> For instance, if it would help, I wouldn't object to changing the default
> for --with-dbus-session-bus-connect-address on Windows to
> "autolaunch:scope=*install-path;autolaunch", 
> or in other words "try a bundled copy,

Recent windows libdbus tries to connect to a session bus from the current install root and start it if not present.

> then fall back to standalone".
 
which will never reached.

Using the opposite 'autolaunch:;autolaunch:scope=*install-path' will search for a standalone session bus first and only the bundled session bus if not found. 

A requirement is that the standalone session bus need to be started on user login or by a windows service.

> If we need any new configuration files, I would strongly prefer to share the
> format and code we already have for .service files, which is freedesktop.org
> .desktop file syntax.

looks doable, something like 

[client]
connect=autolaunch:...
Comment 3 Ralf Habacker 2015-10-04 08:39:53 UTC
Created attachment 118653 [details] [review]
Display autolaunch scope on verbose print of daemon found message on windows.
Comment 4 Ralf Habacker 2015-10-04 09:00:19 UTC
(In reply to Ralf Habacker from comment #2)
> Using the opposite 'autolaunch:;autolaunch:scope=*install-path' will search
> for a standalone session bus first and only the bundled session bus if not
> found. 

If, while processing the 'autolaunch:' address, the standalone session bus has not been found, libdbus tries to start a session bus. The reachable dbus-daemon is configured to listen on 'autolaunch:scope=*install-path', which will then be started. The related session bus will then be found while processing 'autolaunch:;autolaunch:scope=*install-path' address.
Comment 5 Ralf Habacker 2015-10-13 21:33:51 UTC
(In reply to Ralf Habacker from comment #2)

> > If we need any new configuration files, I would strongly prefer to share the
> > format and code we already have for .service files, which is freedesktop.org
> > .desktop file syntax.
> 
> looks doable, something like 
> 
> [client]
> connect=autolaunch:...
Last time we tried to design something based on the desktop spec (relative pathes in service files) it has been rejected because there were not relatedspecifidesktop spec did not definesomething
Comment 6 Ralf Habacker 2015-10-13 21:36:46 UTC
(In reply to Ralf Habacker from comment #5)
> (In reply to Ralf Habacker from comment #2)
> 
> > > If we need any new configuration files, I would strongly prefer to share the
> > > format and code we already have for .service files, which is freedesktop.org
> > > .desktop file syntax.
> > 
> > looks doable, something like 
> > 
> > [client]
> > connect=autolaunch:...
> Last time we tried to design something based on the desktop spec (relative
> pathes in service files) it has been rejected because there were
[pressed save changes by accident, sorry.]
... no related definitions in the spec. 

Based on this experienc will it be possible to add something completly new as the mentioned client connection parameters are ?
Comment 7 Ralf Habacker 2015-10-13 21:45:01 UTC
(In reply to Ralf Habacker from comment #0)

> DBus bundled installation can be configured to use a standalone dbus
> installation or the bundled dbus instance. The latter is reached with the
> 'autolaunch:scope=*install-path' connection string, which is required to be
> configured for the daemon (dbus-1.10: <install-root>/share/dbus-1/session.conf) and all clients. 
> 
I already thought about to create a dedicated dbus binary package with hardcoded configured 'autolaunch:scope=*install-path' address on the client and server side, but dropped that approach because it would introduce big maintenance mess in term of using the same dbus library name with different semantics. Having a client configuraton file looks really to be the best solution for these kind of use cases.
Comment 8 Ralf Habacker 2015-10-13 21:53:29 UTC
(In reply to Ralf Habacker from comment #6)
> Based on this experienc will it be possible to add something completly new
> as the mentioned client connection parameters are ?

Or to ask in date units: Are there any chances that such definitions will go into the desktop spec (and a working patch into dbus-1.10) until 8 November 2015, which is the date of the first KDE Applications 15.12 release (see https://techbase.kde.org/Schedules/Applications/15.12_Release_Schedule for details) ?

Otherwise I see no other way as to use on windows the patch provided to this bug, which is complete and already tested and known to work.
Comment 9 Simon McVittie 2015-10-14 11:56:54 UTC
The .desktop spec is really two separate things:

(1) a .ini-like syntax (GLib's GKeyFile);
(2) a specific instance of that syntax for "Desktop Entry" files
    (GLib's GDesktopAppInfo)

I suspect KDE has separate modules for those layers too, but I don't know what they're called.

In D-Bus, we use the same .ini-like syntax for .service files, but we do not use Desktop Entry (.desktop) files specifically - just like systemd uses a very similar syntax, but not Desktop Entry files.

The particular feature that was rejected for (2) was assigning particular semantics to a relative path for the Exec key. D-Bus' .service files *could* define semantics for relative paths independently, but it would be rather confusing if a valid Exec in a .service file, and a valid Exec in a .desktop file, meant different things.
Comment 10 Simon McVittie 2015-10-14 12:15:00 UTC
(In reply to Ralf Habacker from comment #7)
> I already thought about to create a dedicated dbus binary package with
> hardcoded configured 'autolaunch:scope=*install-path' address on the client
> and server side, but dropped that approach because it would introduce big
> maintenance mess in term of using the same dbus library name with different
> semantics.

If the feature you want is that the system looks for an address using some aspect of the relocatable prefix in which it's installed, having it do that in code seems a *lot* simpler than having it look for a configuration file, then use that configuration file to look up something that end users are not actually expected to configure anyway.

Could we perhaps have something like this?

* a standalone dbus-daemon is configured in session.conf to listen with
  a global address, "autolaunch:";

* a bundled dbus-daemon is configured in session.conf to listen with a
  relocatable address, "autolaunch:scope=*install-path";

* D-Bus client libraries on Windows connect to
  "autolaunch:scope=*install-path;autolaunch:", so that they will work
  either way: if there is a bundled dbus-daemon in the same ${prefix},
  they'll use that; otherwise, they'll try a standalone dbus-daemon

D-Bus client libraries are already expected to be able to try one address, fail, and fall back to another. This would also be a relatively small and easy-to-understand patch for GDBus, GLib's D-Bus reimplementation (assuming they implement the scope option already), whereas I don't think the GLib maintainers would be any more keen on inventing new configuration files than I am.

That's simple to implement: under Autotools, you can do it with the --with-dbus-session-bus-connect-address and --with-dbus-session-bus-listen-address options, no code changes at all. Similarly, in CMake you can do it by setting options. In both cases, adjusting the defaults so that the library "does the right thing" by default would improve the experience for library users, but isn't vital.

(In reply to Ralf Habacker from comment #8)
> Or to ask in date units: Are there any chances that such definitions will go
> into the desktop spec (and a working patch into dbus-1.10) until 8 November
> 2015

There is no requirement to alter the .desktop spec. However, no new configuration files (either XML or not) are going to go into the D-Bus 1.10 branch, because the whole point of a stable branch is that we don't add new code that could cause regressions.

> Otherwise I see no other way as to use on windows the patch provided to this
> bug, which is complete and already tested and known to work.

Changing the compile-time configuration looks like a way to make this work with zero code changes. If you are confident that a particular configuration is the best, we can change the defaults in 1.11, or perhaps even 1.10.
Comment 11 Simon McVittie 2015-10-14 12:59:48 UTC
Bug #38201 has more discussion of whether autolaunch: or autolaunch:scope=*install-path is the better default. It looks as though the GDBus maintainers at the time preferred autolaunch:, so if you want dbus on Windows to interoperate with GDBus on Windows, autolaunch: is a slightly better default.

I think what you're saying in Comment #0 is that autolaunch: is a better default for some situations, autolaunch:scope=*install-path is better for other situations, and there is no setting that can make dbus-daemon correct for both? If that's true, then on the dbus-daemon side, we can't possibly make the default suitable for everyone, and we should just pick one. That's what I did on Bug #38201: autolaunch: interoperates with GDBus, so it seemed a slightly better default. I wouldn't object to reversing that choice in 1.11 if there is a reason why autolaunch:scope=*install-path is a better default, and of course when you're compiling binary releases for KDE you can force whatever configuration you want to.

On the client-side, making the libdbus client library try both ways seems like the best of both worlds: "do the right thing by default" is a lot better than "it can be configured to do the right thing". I think we should probably try autolaunch:scope=*install-path before autolaunch:, because if you have both a standalone dbus-daemon and a bundled dbus-daemon, you probably want to use the bundled one? But if you disagree, putting autolaunch: first would also be fine.

I would really prefer for KDE-on-Windows to not patch/branch libdbus and introduce a new XML configuration file. That seems very unlikely to interoperate with GDBus or other D-Bus implementations.
Comment 12 Simon McVittie 2015-10-14 13:05:47 UTC
Created attachment 118871 [details] [review]
Try autolaunch:scope=*install-path by default on Windows

There are basically two sensible arrangements for dbus-daemon
on Windows. One is to have a standalone system-wide
installation, like on Unix; the other is to bundle a copy of
dbus-daemon with an application or bundle of applications.

These two arrangements cannot agree on a "correct" default
listening address. For a standalone system-wide installation,
autolaunch: is a more appropriate default (and that is
currently what we do on both Autotools and CMake), whereas
for a bundled copy, autolaunch:scope=*install-path makes
more sense.

However, for the default connecting address on the client side,
we can do the right thing in both cases by trying the more
specific address "autolaunch:scope=*install-path" first, then
falling back to the more generic address "autolaunch:" if that
didn't work.

---

This seems to do the right thing under Wine on both Autotools and CMake builds: if I run these in parallel:

DBUS_VERBOSE=1 wine32 dbus-daemon.exe --session --address="autolaunch:scope=*install-path"

DBUS_VERBOSE=1 wine32 dbus-daemon.exe --session --address=autolaunch:

and then connect, using env -u to wipe out my existing DBUS_SESSION_BUS_ADDRESS:

env -u DBUS_SESSION_BUS_ADDRESS wine32 dbus-monitor.exe --session

I get a connection to the instance with autolaunch:scope=*install-path. If I Ctrl+C that instance and re-run dbus-monitor, I get a connection to the other instance.

Please test on real Windows, but this seems to get the job done without needing to introduce new configuration.

This is sufficiently minimal, and sufficiently isolated to Windows code paths, that I think it could perhaps even go in 1.10. If it doesn't, getting the same effect with current releases is just a matter of compile-time configuration anyway.
Comment 13 Ralf Habacker 2015-10-16 21:21:51 UTC
(In reply to Simon McVittie from comment #10)
> Could we perhaps have something like this?
> 
> * a standalone dbus-daemon is configured in session.conf to listen with
>   a global address, "autolaunch:";
agreed
 
> * a bundled dbus-daemon is configured in session.conf to listen with a
>   relocatable address, "autolaunch:scope=*install-path";
agreed 

> * D-Bus client libraries on Windows connect to
>   "autolaunch:scope=*install-path;autolaunch:", so that they will work
>   either way: if there is a bundled dbus-daemon in the same ${prefix},
>   they'll use that; otherwise, they'll try a standalone dbus-daemon

The conclusion is that end users need to remove or rename the dbus-daemon.exe from the bundled installation (which disables the autostart) to select the standalone variant. If no dbus daemon from a standalone package has been started no session bus will available.
Comment 14 Ralf Habacker 2015-10-16 21:42:02 UTC
(In reply to Ralf Habacker from comment #13)
> (In reply to Simon McVittie from comment #10)
> > Could we perhaps have something like this?
> > 
> > * a standalone dbus-daemon is configured in session.conf to listen with
> >   a global address, "autolaunch:";
> agreed
>  
> > * a bundled dbus-daemon is configured in session.conf to listen with a
> >   relocatable address, "autolaunch:scope=*install-path";

Because I do not want to have two different dbus binary packages on windows (see comment 7)
this need to be set up by the packager on building the bundled package for example mingw32-umbrello-installer. From the dbus-1.10 session.conf documentation I see that this could be achieved by a session-local.conf in etc/dbus-1. Something like this ?

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <listen>autolaunch:scope=*install-path</listen>
</busconfig>
Comment 15 Simon McVittie 2015-10-19 11:15:28 UTC
(In reply to Ralf Habacker from comment #13)
> The conclusion is that end users need to remove or rename the
> dbus-daemon.exe from the bundled installation (which disables the autostart)
> to select the standalone variant. If no dbus daemon from a standalone
> package has been started no session bus will available.

I think this might be what you mean anyway, but re-stating it to be absolutely clear:

If the end user wants to use the bundled dbus-daemon, they don't do anything special: they leave it in place, and it works.

If end users want to use a separately-installed standalone dbus-daemon, yes they will need to remove or rename the bundled dbus-daemon. If they, incorrectly, do this without also having a separately-installed dbus-daemon, then D-Bus won't work. This does not seem bad or unusual: deleting files without knowing that they are unnecessary rarely ends well :-)

I think that's what we want: a bundled dbus-daemon in a self-contained package is clearly intended to be what's used, unless the user deliberately takes steps to use a separately-installed dbus-daemon instead. Or are you saying this is not desirable?

(In reply to Ralf Habacker from comment #14)
> Because I do not want to have two different dbus binary packages on windows
> (see comment 7)
> this need to be set up by the packager on building the bundled package for
> example mingw32-umbrello-installer. From the dbus-1.10 session.conf
> documentation I see that this could be achieved by a session-local.conf in
> etc/dbus-1. Something like this ?
> 
> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration
> 1.0//EN"
>  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
> <busconfig>
>   <listen>autolaunch:scope=*install-path</listen>
> </busconfig>

For the bundling use-case, I think you want to *replace* the listen address, whereas this would *add* a listen address.

My suggestion would be for the packager of a bundled package to edit share/dbus-1/session.conf (on 1.10+) or etc/dbus-1/session.conf (on 1.8 or older), for instance using sed or xmlstarlet.

I assume that to make a standalone Umbrello installer, you copy Umbrello itself, plus the standalone version of dbus and any other dependencies there might be, into some temporary root (analogous to Autotools' DESTDIR), and then pack up that temporary root into an installer? If you're doing that, perhaps you can edit the bundled session.conf after copying but before packing?
Comment 16 Ralf Habacker 2015-10-21 00:41:44 UTC
(In reply to Simon McVittie from comment #15)
> I think this might be what you mean anyway, but re-stating it to be
> absolutely clear:
> 
> If the end user wants to use the bundled dbus-daemon, they don't do anything
> special: they leave it in place, and it works.
agreed
> If end users want to use a separately-installed standalone dbus-daemon, yes
> they will need to remove or rename the bundled dbus-daemon. If they,
> incorrectly, do this without also having a separately-installed dbus-daemon,
> then D-Bus won't work. 
agreed. I still need to think about to deal with installer updates, which may reinstall/overwrite original dbus-daemon.exe.

> I think that's what we want: a bundled dbus-daemon in a self-contained
> package is clearly intended to be what's used, unless the user deliberately
> takes steps to use a separately-installed dbus-daemon instead. 
This is desirable. 

> For the bundling use-case, I think you want to *replace* the listen address,
> whereas this would *add* a listen address.
> 
> My suggestion would be for the packager of a bundled package to edit
> share/dbus-1/session.conf (on 1.10+) 

I use cmake, see https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32/mingw32-umbrello-installer/CMakeLists.txt?expand=1

> or etc/dbus-1/session.conf (on 1.8 or older), 
currently only dbus 1.10+ is supported.

> I assume that to make a standalone Umbrello installer, you copy Umbrello
> itself, plus the standalone version of dbus and any other dependencies there
> might be, 
yes, see https://build.opensuse.org/package/show/home:rhabacker:branches:windows:mingw:win32/mingw32-umbrello-installer

> into some temporary root (analogous to Autotools' DESTDIR), and
> then pack up that temporary root into an installer? 
yes using cpack 
> If you're doing that, perhaps you can edit the bundled session.conf after 
> copying but before packing?

yes, see above.
Comment 17 Simon McVittie 2015-10-21 14:38:10 UTC
(In reply to Simon McVittie from comment #15)
> My suggestion would be for the packager of a bundled package to edit
> share/dbus-1/session.conf (on 1.10+) or etc/dbus-1/session.conf (on 1.8 or
> older), for instance using sed or xmlstarlet.

I see you've done that in your Umbrello packaging. Does that, plus Attachment #118871 [details], solve your problem?

I would really prefer to do something like Attachment #118871 [details] rather than adding all the machinery for a client-side configuration file. That seems more likely to be accepted by non-libdbus client implementations (GDBus, dbus-sharp, dbus-java, ...) as well.
Comment 18 Ralf Habacker 2015-10-23 10:07:32 UTC
(In reply to Simon McVittie from comment #17)
> (In reply to Simon McVittie from comment #15)
> > My suggestion would be for the packager of a bundled package to edit
> > share/dbus-1/session.conf (on 1.10+) or etc/dbus-1/session.conf (on 1.8 or
> > older), for instance using sed or xmlstarlet.
> 
> I see you've done that in your Umbrello packaging. Does that, plus
> Attachment #118871 [details], solve your problem?
> 
I will come to this back this weekend.
Comment 19 Simon McVittie 2015-10-27 11:16:53 UTC
Comment on attachment 118653 [details] [review]
Display autolaunch scope on verbose print of daemon found message on windows.

Review of attachment 118653 [details] [review]:
-----------------------------------------------------------------

Sure. This is small enough that I wouldn't object to it in 1.10, even though it isn't strictly a bugfix.
Comment 20 Simon McVittie 2015-10-27 11:17:40 UTC
Comment on attachment 118871 [details] [review]
Try autolaunch:scope=*install-path by default on Windows

Review of attachment 118871 [details] [review]:
-----------------------------------------------------------------

This didn't make it into 1.10.2 because I wanted to get the other fixes released, but I wouldn't mind putting it in 1.10.4.
Comment 21 Ralf Habacker 2015-10-27 12:16:01 UTC
Comment on attachment 118653 [details] [review]
Display autolaunch scope on verbose print of daemon found message on windows.

committed to dbus-1.10
Comment 22 Ralf Habacker 2015-10-27 12:39:46 UTC
(In reply to Simon McVittie from comment #17)
> (In reply to Simon McVittie from comment #15)
> > My suggestion would be for the packager of a bundled package to edit
> > share/dbus-1/session.conf (on 1.10+) or etc/dbus-1/session.conf (on 1.8 or
> > older), for instance using sed or xmlstarlet.
> 
> I see you've done that in your Umbrello packaging. Does that, plus
> Attachment #118871 [details], solve your problem?

As stated in Comment #16 there is still an issue how to deal with the fact that I need to remove dbus-daemon.exe from the bundled package to use the default session bus. On the next update of a bundled package the dbus-daemon is restored and will use the local daemon again.

Additional there is no chance to change the client *default* settings after an installation. If there is the need to change session bus config I'm able to add a session-local.conf to modify any settings, but not so for the client. In that case there is an update of the installation package required.

As you do not like a settings file for client default settings, I already thought to use a registry key for the client default settings instead, but this is much more worse to deal with for portable installations unpackaged from a tar ball, because the install path need to be tracked in the registry.

An alternative would be to store the client default setting in big strings in the dll to be able to patch that binary afterwards, but the problem is that you cannot see from outside the binary that there are custom settings inside.

In analogy to the daemon part I'm convinced that having an optional "client-local.conf" or "client-defaults.conf" file to change client *default* settings like DBUS_SESSION_BUS_ADDRESS   (I'm saying 'default' because _dbus_lookup_session_address() is only called if no BUS_SESSION_BUS_ADDRESS environment is set) and other default settings like verbose mode and probably others in the future will fit all needs for gui environments like windows.

This file should not be part of the installation to preserve it from been overwritten next time the user updates the installation.
Comment 23 Simon McVittie 2015-11-02 18:12:36 UTC
(In reply to Ralf Habacker from comment #22)
> As stated in Comment #16 there is still an issue how to deal with the fact
> that I need to remove dbus-daemon.exe from the bundled package to use the
> default session bus.

Is that useful to do in practice? The bundled dbus-daemon will search the same installation prefix for activatable services, but the other (system-wide) dbus-daemon won't. I suppose this could still be used by manually-launched D-Bus-using apps that communicate only with each other and not with activatable services, but that seems quite narrow?

> Additional there is no chance to change the client *default* settings after
> an installation.

I think that's somewhat deliberate. The general philosophy is that it's OK for the dbus-daemon to have configuration, because everyone uses the reference dbus-daemon, and there is only one of it per well-known bus type; but client implementations should do something relatively simple, understandable and documentable to find their dbus-daemon, because there are multiple client implementations (libdbus, sd-bus, GDBus, dbus-sharp, dbus-java), which should all interoperate, ideally by all doing the same thing described by the D-Bus Specification.

D-Bus on Windows does undermine the idea that there's only one dbus-daemon per well-known bus type, because autolaunch:scope=*install-path creates "islands" where the session bus has a different meaning. I think that's unavoidable if you're bundling things in a relocatable prefix, though...

I'd be happier about the use of configuration files if they were a feature of a particular transport (such as the Windows flavour of autolaunch:) rather than being something that is used by the library generally. autolaunch: is really two unrelated transports - the Unix and Windows implementations are very different - so giving the Windows implementation some odd Windows-specific semantics would be no great loss.

Perhaps we could redefine autolaunch: to be something like this?

If the autolaunch scope is "*install-path":

* read (relocated prefix)/etc/dbus-1/autolaunch.conf

* if it exists, it should have contents something like this:

    [D-Bus Windows autolaunch]
    Exec=C:/D-Bus/bin/dbus-daemon.exe

  and libdbus executes that version of dbus-daemon

* if it does not exist, or does not contain Exec in the desired group,
  libdbus executes (relocated prefix)/bin/dbus-daemon.exe as usual

(I would recommend using forward slashes, because backslash is an escape character in .desktop-style syntax, so you have to say C:\\D-Bus\\bin if you use backslashes.)

I'd also be a lot happier with the .desktop-style format than XML. I think you'd need to move bus/desktop-file.[ch] into dbus/, rename their symbols to _dbus_whatever(), and make them DBUS_PRIVATE_EXPORT so the dbus-daemon can continue to use them - please do that as a separate commit first, if you're going this route.

This all seems like a job for 1.11, although of course you can backport selected features (such as this one) into your modified distribution of dbus.

(In reply to Ralf Habacker from comment #22)
> other default settings like
> verbose mode and probably others in the future

I don't want libdbus to have "configuration" in general, because it's a library with an API. We configure libraries by calling functions, not by creating configuration files.

DBUS_SESSION_BUS_ADDRESS and DBUS_SYSTEM_BUS_ADDRESS are less configuration and more system-integration glue. Ideally, neither would ever need to be set, except in regression tests (in practice lots of things rely on them at the moment, but we might get there in a few years).

Verbose mode, fatal warnings and the other things that are affected by environment variables are more like configuration, but they're also debugging/development features, rather than anything that should be adjusted at runtime in production.
Comment 24 Ralf Habacker 2015-11-11 22:55:30 UTC
(In reply to Simon McVittie from comment #23)

> I'd also be a lot happier with the .desktop-style format than XML. I think
> you'd need to move bus/desktop-file.[ch] into dbus/, rename their symbols to
> _dbus_whatever(), and make them DBUS_PRIVATE_EXPORT so the dbus-daemon can
> continue to use them -
> please do that as a separate commit first, if you're going this route.

Regardless of the concrete route, I tried to move those files to dbus subdir, but failed to add them to the dbus-1 library as private symbols, because it depends on _dbus_stat, which is located in dbus-internal library. Because dbus-internal depends on dbus-1, there is a cross dependency. It would be required to move _dbus_stat also to dbus-1 library as private symbol. Moving complete dbus-sysdeps-util-win.c into dbus-1 looks like a much bigger job :-(
Comment 25 Simon McVittie 2015-11-17 14:41:21 UTC
(In reply to Ralf Habacker from comment #24)
> It
> would be required to move _dbus_stat also to dbus-1 library as private
> symbol.

That's a valid thing to consider doing, if it's necessary (although I would still prefer not to load a configuration file from a library).

> Moving complete dbus-sysdeps-util-win.c into dbus-1 looks like a
> much bigger job :-(

That would be wrong. dbus-sysdeps-util-*.c are the utility functions that are not in dbus-1, which have weaker requirements than dbus-sysdeps-{unix,win}.c (in particular they are not required to be thread-safe). If a particular utility function is needed by dbus-1, the right thing to do is to move that single function from dbus-sysdeps-util-{unix,win}.c to dbus-sysdeps-{unix,win}.c.
Comment 26 Simon McVittie 2015-11-17 14:56:30 UTC
(In reply to Ralf Habacker from comment #24)
> but failed to add them to the dbus-1 library as private symbols,
> because it depends on _dbus_stat, which is located in dbus-internal library

This actually looks rather pointless. We only use _dbus_stat() to do an early-exit if the file is > 128K... but then we call _dbus_file_get_contents(), which errors out if the file is > 1M anyway!

A better way to do this would be to give _dbus_file_get_contents() a "maximum size" argument, and skip the _dbus_stat()... or relax the limit and allow reading .desktop files in the range 128K to 1M, given that those limits are completely arbitrary anyway.

_dbus_stat() and DBusStatBuf aren't a very good cross-platform abstraction: they fill in lots of information that makes no sense on Windows, like the "executable" bit in statbuf->mode. The only information we actually *use* is:

* whether stat() succeeds at all, i.e. the file exists and is in a readable
  directory
* the modification time
* the size (in the .desktop reader)
* the uid, in Unix-specific code that could equally well use stat() directly

so we'd be better off with something more like _dbus_file_get_mtime().
Comment 27 GitLab Migration User 2018-10-12 21:23:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/131.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.