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

[Ralf Habacker]

  Am 28.09.2010 16:16, schrieb 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
I will come back to this in the next few days - in short:


The specs says  in <sect1 id="addresses">

       Server addresses consist of a transport name followed by a colon, and
       then an optional, comma-separated list of keys and values in the 
form key=value.
       Each value is escaped.

According to this spec the term 'autolaunch:' is a transport name.

Additional it connects to a server by a real available transport. On the 
server side autolaunch uses a real available transport for listening.  
The used type of transport is an plattform specific implementation detail.

Looking at this I recognized that 'autolaunch' is more than an address 
because

1. it provides a dedicated transport name on the client and the server side
2. it opens a specific communication channel like other transports to a 
server (shared memory on windows,  X selections on unix)
3. it uses available transports depending on the plattform

I would say that autolaunch is a kind of meta transport. Using the term 
'meta transport' would make this special feature more clear and will 
indicate that autolaunch could be used as transport (which is the trueth).

In the future there may be additional  meta' transports for specific use 
cases or available meta transports may get more features [1] - who knows.

[1] Currently the transport used by autolaunch is hardcoded in the code 
- there may be uses cases out there, which requires to have this 
configurable.

Regards
  Ralf