D-Bus spec issue (Was Re: Windows DBus shared memory name depends on _DEBUG?)

[David Zeuthen]

Hey Ralf,

On Sun, Sep 26, 2010 at 1:21 PM, Ralf Habacker <ralf.habacker at freenet.de> wrote:
> If there are no more objectivies I will apply these patches in the next days
> along with the autolaunch spec update.

Thanks for the effort of writing the patch

 http://cgit.freedesktop.org/dbus/dbus/commit/?id=2e61875728deca49a96e2db52275f3a5e24bb59b

documenting the autolaunch: transport. I don't think it's quite right:

First, autolaunch: isn't really a transport - it's an implementation
detail of the dbus codebase. It really shouldn't be in the spec. E.g.
we don't want to require every implementation of the D-Bus protocol
(such as GDBus or NDesk) to support such a complicated "transport"
(which isn't a transport in the first place - if anything, it's an
address string).

Second, in <sect3
id="transports-autolaunch-windows-implementation-notes"> you mention
how to obtain the session bus address on Windows (including possibly
launching a bus if necessary). This is good but it really isn't an
implementation detail - it's really necessary to implement this in
each and every D-Bus implementation that is supposed to work on
Windows.

Here's what I would do

1. Revert the patch

2. Add a simple blurb to the "Login session message bus" subsection of
the "Well-known Message Bus Instances" section, see

  http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-types

that specifies how to obtain (and set) the session bus address on
Win32 (e.g. the part with cDBusDaemonMutex and DBusDaemonAddressInfo).
Ideally as simple as what we have for X11 [1]:

    If that variable is not set, applications may also try to read the
address from
    the X Window System root window property _DBUS_SESSION_BUS_ADDRESS.
    The root window property must have type STRING.

What do you think about this?

Thanks,
David

[1] : The X11 part of this is actually wrong and the spec needs to be
updated to reflect the current behavior. But that's orthogonal to the
problem at hand.