Cmake update patch for dbus master

[Ralf Habacker]

Tor Lillqvist schrieb:
 >> The only way I see is to use installation path based shared memory 
segments.
 >>     
 >
 > I was first going to say that this sounds like a good idea, but then I
 > started thinking.
 >
 > Consider this scenario: Several apps distributed by different people
 > use dbus. No app directly requires another, but there is some useful
 > information oner app can send on the bus to another app if present.
 >   
For this purpose a global user session dbus daemon should be installable
as as a standalone package which let the user session daemon start
on user session logon.

 > All apps come bundled with dbus
 > and all install the dbus daemon and client library under their own 
installation folder. This is what one
 > should do, right?
 >   
The minimal requirement for apps should be a bundled dbus library to be 
able to connect to a dbus-daemon. The dbus-daemon may be bundled too but 
could be optional.

 > So if the name of the shared memory segment is based on where the dbus
 > client library (DLL) is installed, these apps will be using different
 > session buses, and won't be able to talk to the others.
 >   
By default a dbus daemon of a specific application should be configured
on package build time to run a local session bus and the app to connect
to these local session bus.

On application install time the related installer could check if there
is a user session bus daemon installed and could then offer a way to
configure the bundled dbus to use the global user session bus. Maybe the
standalone dbus package could have a little config gui for this purpose 
to minimize the required installers effort.

 > So does you suggestion implicitly require that people who build
 > installers for Windows apps that use dbus and that *want* the session
 > bus instance their app uses is able to talk to whatever other apps
 > there are present agree on a way to install

Is a standalone dbus package not be able install a config file into a 
well known location or to set a well known registry key which is 
readable by all bundled dbus client libraries ?

 > (possibly update a previous installation of) > a shared copy of dbus?

The standalone dbus package could have a buildin updater, which could be 
started from other installers.

 > I think that will be
 > quite hard to achieve. Some people like MSI-based installer
 > technology, some might not like it but feel it is required for
 > "enterprise readiness", others won't touch it with a stick and prefer
 > NSIS, others prefer InnoSetup, etc etc.
 >

This depends on how simple the agreement is. Current windows dbus code 
provides well known shared memory areas for the session bus address for 
client connecting purpose, so the mimimum would be a config file on a 
well known location containing
- the path of the related daemon for autostart purposes
- for installers the path of the standalone package updater

Do have I overseen something ?

Regards
Ralf