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

[Ralf Habacker]

  Am 28.09.2010 20:13, schrieb Thiago Macieira:
> Em Terça-feira 28 Setembro 2010, às 16:16:57, David Zeuthen escreveu:
>> 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).
> What needs to be specified is what a binding must do if it is told to connect
> to "autolaunch:".
As far as I know there is nothing to do for a binding. In case of the 
python binding there is the following code to get a session bus

     import dbus

     session_bus = dbus.SessionBus()

>   How the code does that is beyond the scope.
>> 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.
> Agreed.

>> 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]:
the part below looks not very simple :-)
Additional on windows there is currently no "login session bus"  available.

Placing this whole stuff into a meta transport section and placing here 
a short note with a reference to this section wil make this much clearer.

>>      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?
> Well, that part:
>
>> [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.
> Yeah :-)
>
> Here's some wording:
>
> If DBUS_SESSION_BUS_ADDRESS is not set, or if it's set to the string
> "autolaunch:", the system should use platform-specific methods of locating a
> running D-Bus session server, or starting one if a running instance cannot be
> found.
>
> Note that this mechanism is not recommended for attempting to determine if a
> daemon is running. It is inherently racy to attempt to make this
> determination, since the bus daemon may be started just before or just after
> the determination is made. Therefore, it is recommended that applications do
> not try to make this determination for their functionality purposes, and
> instead they should attempt to start the server.
>
> X Windowing System
> --------
>
> For the X Windowing System, the application must locate the window owner of
> the selection represented by the atom formed by concatenating:
>
> 	the literal string "_DBUS_SESSION_BUS_SELECTION_"
> 	the current user's username
> 	the literal character '_' (underscore)
> 	the machine's ID
>
> The following properties are defined for the window that owns this X selection:
>
> 	Atom						meaning
> 	_DBUS_SESSION_BUS_ADDRESS	the actual address of the server socket
> 	_DBUS_SESSION_BUS_PID			the PID of the server process
>
> At least the _DBUS_SESSION_BUS_ADDRESS property MUST be present in this
> window.
>
> If the X selection cannot be located or if reading the properties from the
> window fails, the implementation MUST conclude that there is no D-Bus server
> running and proceed to start a new server. (See below on concurrency issues)
>
> Failure to connect to the D-Bus server address thus obtained MUST be treated
> as a fatal connection error and should be reported to the application.
>
> As an alternative, an implementation MAY find the information in the following
> file located in the current user's home directory, in subdirectory
> .dbus/session-bus/:
>
> 	the machine's ID
> 	the literal character '-' (dash)
> 	the X display without the screen number, with the following prefixes 		
> 		removed, if present:
> 		- ":"
> 		- "localhost:"
> 		- "localhost.localdomain:"
> 		that is, a display of "localhost:10.0" produces just the number "10"
>
> The contents of this file NAME=value assignment pairs and lines starting with #
> are comments (no comments are allowed otherwise). The following variable names
> are defined:
> 		
> 	Variable						meaning
> 	DBUS_SESSION_BUS_ADDRESS		the actual address of the server socket
> 	DBUS_SESSION_BUS_PID			the PID of the server process
> 	DBUS_SESSION_BUS_WINDOWID	the window ID
>
> At least the DBUS_SESSION_BUS_ADDRESS variable MUST be present in this file.
>
> Failure to open this file MUST be interpreted as absence of a running server.
> Therefore, the implementation MUST proceed to attempting to launch a new bus
> server if the file cannot be opened.
>
> However, success in opening this file MUST NOT lead to the conclusion that the
> server is running. Thus, a failure to connect to the bus address obtained by
> the alternative method MUST NOT be considered a fatal error. If the connection
> cannot be established, the implementation MUST proceed to check the X
> selection settings or to start the server on its own.
>
> If the implementation concludes that the D-Bus server is not running it MUST
> attempt to start a new server and it MUST also ensure that the daemon started
> as an effect of the "autolaunch" mechanism provides the lookup mechanisms
> described above, so subsequent calls can locate the newly started server. The
> implementation MUST also ensure that if two or more concurrent initiations
> happen, only one server remains running and all other initiations are able to
> obtain the address of this server and connect to it. In other words, the
> implementation MUST ensure that the X selection is not present when it
> attempts to set it, without allowing another process to set the selection
> between the verification and the setting (e.g., by using XGrabServer /
> XUngrabServer).
>
the following should be completly in a author note ?
<note>
> Note: I think the X selection atom should include the user's ID (UID), not the
> username. We can change this and simply set both selections until D-Bus 1.6.
>
> The above makes it so that the X selection&  property mechanism is
> authoritative necessary and sufficient condition: the absence of the information
> means the server is *definitely* not running (right now, at least) and its
> presence means the server is *definitely* running.
>
> The file in $HOME is not authoritative: it's a way for an implementation to
> perform a connection without consulting the X server or running dbus-launch.
> The presence of the file is only a necessary condition: if the server is
> running, the file is present and contains correct information. However, the file
> may be present and the server may not be running (e.g., stale file). That's why
> failing to connect to the socket should not be a fatal error.
>
> I also wrote it in such a way that implementations are not allowed to query
> for whether the server is running.
</note>
Regards
  Ralf