D-Bus windows help

[Simon McVittie]

On 11/07/12 20:39, Alexander Larsson wrote:
>> There are also two patches awaiting review on that bug which change the
>> default address on Windows to "autolaunch:scope=*install-path" (it'd be
>> easy to switch to plain "autolaunch:" if that's more desirable).
> 
> GDbus on win32 doesn't support any of the scopes. install-path for
> instance doesn't seem to be a great choice for gdbus as it ties the
> implementation-independent protocol to an implementation (and gdbus is a
> non-libdbus client implementation).

I've commented on #38201 and added you to the Cc there.

Briefly, it seems that:

* If you want things to work like they do on Unix, with each Windows
  login session having a single session bus and one copy of each
  singleton service, then "autolaunch:" or possibly even
  "autolaunch:scope=*user" is the right default. (It's not clear to
  me whether plain "autolaunch:" automatically has a per-user scope.)
  This necessarily means that applications on this bus might be
  different versions of the same app or stack, or be in different
  configurations (debug vs. release or whatever), or the dbus-daemon
  that was autolaunched might be an older version than the one that
  came with the application. The authors of GDBus appear to believe in
  this world-view. Some of Ralf's comments on #38201 seem to indicate
  that this is what he wants in the long term.

* If you want each user-installed bundle (app, or installer that
  results in multiple apps) to live in its own little world, then
  "autolaunch:scope=*install-path" is the right default. This means
  that apps from different "bundles" are isolated from each other:
  they can't communicate, but they can't break each other either.
  You can have a "release version of KDE SC" and a "debug version of
  KDE SC" and they don't interfere with each other. The KDE-on-Windows
  developers appear to believe in this world-view.

We can't have it both ways - DBUS_BUS_SESSION has to mean *something* by
default - but we can at least make it easy for distributors who don't
like one of those interpretations to choose the other one.

Until a decision is made, the default is "nonce-tcp:" which is clearly
not the right default - it isn't a valid client-side address, so it
doesn't work out-of-the-box! - and everyone loses.

Until someone reviews the patches I proposed on #38201 and either says
"yes, please apply" or explains what we should do instead, the defaults
are inconsistent between Autotools and CMake, and, again, everyone loses.

I am increasingly tempted to apply the patches from #38201, choosing
between "autolaunch:" or "autolaunch:scope=*install-path" at random, and
if there's later consensus that the chosen option was the wrong one then
we can change it.

    S