X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=doc%2Fdbus-specification.xml;h=7280cf1768611b037b8168796e3e2031fddfb5a6;hb=b080ba1eab764b79edb62afcfc61794f410a5591;hp=0e3a1783412a12c0c1e66b6ff7015a4bdef24bf5;hpb=5d64b7a1b792789fd1d41ad99624b578dddcf4b4;p=platform%2Fupstream%2Fdbus.git diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 0e3a178..7280cf1 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -3,12 +3,11 @@ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ ]> -
D-Bus Specification - Version 0.14 - May 12, 2010 + Version 0.19 + UNRELEASED Havoc @@ -40,7 +39,114 @@ + + Sven + Herzberg + + Imendio AB +
+ sven@imendio.com +
+ + + + Simon + McVittie + + Collabora Ltd. +
+ simon.mcvittie@collabora.co.uk +
+ + + + David + Zeuthen + + Red Hat, Inc. +
+ davidz@redhat.com +
+ + + + + current + commit log + + + + + 0.18 + 29 July 2011 + smcv + define eavesdropping, unicast, broadcast; add eavesdrop + match keyword; promote type system to a top-level section + + + 0.17 + 1 June 2011 + smcv/davidz + define ObjectManager; reserve extra pseudo-type-codes used + by GVariant + + + 0.16 + 11 April 2011 + + add path_namespace, arg0namespace; argNpath matches object + paths + + + 0.15 + 3 November 2010 + + + + + 0.14 + 12 May 2010 + + + + + 0.13 + 23 Dezember 2009 + + + + + 0.12 + 7 November, 2006 + + + + + 0.11 + 6 February 2005 + + + + + 0.10 + 28 January 2005 + + + + + 0.9 + 7 Januar 2005 + + + + + 0.8 + 06 September 2003 + + First released document. + + @@ -165,27 +271,13 @@ - - Message Protocol + + Type System - A message consists of a - header and a body. If you - think of a message as a package, the header is the address, and the body - contains the package contents. The message delivery system uses the header - information to figure out where to send the message and how to interpret - it; the recipient interprets the body of the message. - - - - The body of the message is made up of zero or more - arguments, which are typed values, such as an - integer or a byte array. - - - - Both header and body use the same type system and format for - serializing data. Each type of value has a wire format. + D-Bus has a type system, in which values of various types can be + serialized into a sequence of bytes referred to as the + wire format in a standard way. Converting a value from some other representation into the wire format is called marshaling and converting it back from the wire format is unmarshaling. @@ -406,7 +498,10 @@ STRUCT 114 (ASCII 'r'), 40 (ASCII '('), 41 (ASCII ')') - Struct + Struct; type code 114 'r' is reserved for use in + bindings and implementations to represent the general + concept of a struct, and must not appear in signatures + used on D-Bus. VARIANT 118 (ASCII 'v') @@ -414,12 +509,48 @@ DICT_ENTRY 101 (ASCII 'e'), 123 (ASCII '{'), 125 (ASCII '}') - Entry in a dict or map (array of key-value pairs) + Entry in a dict or map (array of key-value pairs). + Type code 101 'e' is reserved for use in bindings and + implementations to represent the general concept of a + dict or dict-entry, and must not appear in signatures + used on D-Bus. UNIX_FD 104 (ASCII 'h') Unix file descriptor + + (reserved) + 109 (ASCII 'm') + Reserved for a + 'maybe' type compatible with the one in GVariant, + and must not appear in signatures used on D-Bus until + specified here + + + (reserved) + 42 (ASCII '*') + Reserved for use in bindings/implementations to + represent any single complete type, + and must not appear in signatures used on D-Bus. + + + (reserved) + 63 (ASCII '?') + Reserved for use in bindings/implementations to + represent any basic type, and must + not appear in signatures used on D-Bus. + + + (reserved) + 64 (ASCII '@'), 38 (ASCII '&'), + 94 (ASCII '^') + Reserved for internal use by bindings/implementations, + and must not appear in signatures used on D-Bus. + GVariant uses these type-codes to encode calling + conventions. + @@ -565,12 +696,14 @@ VARIANT - A variant type has a marshaled SIGNATURE - followed by a marshaled value with the type - given in the signature. - Unlike a message signature, the variant signature - can contain only a single complete type. - So "i", "ai" or "(ii)" is OK, but "ii" is not. + A variant type has a marshaled + SIGNATURE followed by a marshaled + value with the type given in the signature. Unlike + a message signature, the variant signature can + contain only a single complete type. So "i", "ai" + or "(ii)" is OK, but "ii" is not. Use of variants may not + cause a total message depth to be larger than 64, including + other container types such as structures. 1 (alignment of the signature) @@ -703,6 +836,31 @@ + + + + Message Protocol + + + A message consists of a + header and a body. If you + think of a message as a package, the header is the address, and the body + contains the package contents. The message delivery system uses the header + information to figure out where to send the message and how to interpret + it; the recipient interprets the body of the message. + + + + The body of the message is made up of zero or more + arguments, which are typed values, such as an + integer or a byte array. + + + + Both header and body use the D-Bus type + system and format for serializing data. + + Message Format @@ -2409,8 +2567,8 @@ [FIXME we need to specify in detail each transport and its possible arguments] Current transports include: unix domain sockets (including - abstract namespace on linux), TCP/IP, and a debug/testing transport using - in-process pipes. Future possible transports include one that + abstract namespace on linux), launchd, TCP/IP, and a debug/testing transport + using in-process pipes. Future possible transports include one that tunnels over X11 protocol. @@ -2469,6 +2627,53 @@ + + launchd + + launchd is a open-source server management system that replaces init, inetd + and cron on Apple Mac OS X versions 10.4 and above. It provides a common session + bus address for each user and deprecates the X11-enabled D-Bus launcher on OSX. + + + + launchd allocates a socket and provides it with the unix path through the + DBUS_LAUNCHD_SESSION_BUS_SOCKET variable in launchd's environment. Every process + spawned by launchd (or dbus-daemon, if it was started by launchd) can access + it through its environment. + Other processes can query for the launchd socket by executing: + $ launchctl getenv DBUS_LAUNCHD_SESSION_BUS_SOCKET + This is normally done by the D-Bus client library so doesn't have to be done + manually. + + + launchd is not available on Microsoft Windows. + + + Server Address Format + + launchd addresses are identified by the "launchd:" prefix + and support the following key/value pairs: + + + + + + Name + Values + Description + + + + + env + (environment variable) + path of the unix domain socket for the launchd created dbus-daemon. + + + + + + TCP Sockets @@ -2598,10 +2803,96 @@ + + + Meta Transports + + Meta transports are a kind of transport with special enhancements or + behavior. Currently available meta transports include: autolaunch + - + + Autolaunch + The autolaunch transport provides a way for dbus clients to autodetect + a running dbus session bus and to autolaunch a session bus if not present. + + + Server Address Format + + Autolaunch addresses uses the "autolaunch:" prefix and support the + following key/value pairs: + + + + + + Name + Values + Description + + + + + scope + (string) + scope of autolaunch (Windows only) + + + + "*install-path" - limit session bus to dbus installation path. + The dbus installation path is determined from the location of + the shared dbus library. If the library is located in a 'bin' + subdirectory the installation root is the directory above, + otherwise the directory where the library lives is taken as + installation root. + + <install-root>/bin/[lib]dbus-1.dll + <install-root>/[lib]dbus-1.dll + + + + + + "*user" - limit session bus to the recent user. + + + + + other values - specify dedicated session bus like "release", + "debug" or other + + + + + + + + + - + + Windows implementation + + On start, the server opens a platform specific transport, creates a mutex + and a shared memory section containing the related session bus address. + This mutex will be inspected by the dbus client library to detect a + running dbus session bus. The access to the mutex and the shared memory + section are protected by global locks. + + + In the recent implementation the autolaunch transport uses a tcp transport + on localhost with a port choosen from the operating system. This detail may + change in the future. + + + Disclaimer: The recent implementation is in an early state and may not + work in all cirumstances and/or may have security issues. Because of this + the implementation is not documentated yet. + + + + + Naming Conventions @@ -2791,6 +3082,114 @@ annotation. + + + <literal>org.freedesktop.DBus.ObjectManager</literal> + + An API can optionally make use of this interface for one or + more sub-trees of objects. The root of each sub-tree implements + this interface so other applications can get all objects, + interfaces and properties in a single method call. It is + appropriate to use this interface if users of the tree of + objects are expected to be interested in all interfaces of all + objects in the tree; a more granular API should be used if + users of the objects are expected to be interested in a small + subset of the objects, a small subset of their interfaces, or + both. + + + The method that applications can use to get all objects and + properties is GetManagedObjects: + + + + org.freedesktop.DBus.ObjectManager.GetManagedObjects (out DICT<OBJPATH,DICT<STRING,DICT<STRING,VARIANT>>> objpath_interfaces_and_properties); + + + + The return value of this method is a dict whose keys are + object paths. All returned object paths are children of the + object path implementing this interface, i.e. their object + paths start with the ObjectManager's object path plus '/'. + + + Each value is a dict whose keys are interfaces names. Each + value in this inner dict is the same dict that would be + returned by the org.freedesktop.DBus.Properties.GetAll() + method for that combination of object path and interface. If + an interface has no properties, the empty dict is returned. + + + Changes are emitted using the following two signals: + + + + org.freedesktop.DBus.ObjectManager.InterfacesAdded (OBJPATH object_path, + DICT<STRING,DICT<STRING,VARIANT>> interfaces_and_properties); + org.freedesktop.DBus.ObjectManager.InterfacesRemoved (OBJPATH object_path, + ARRAY<STRING> interfaces); + + + + The InterfacesAdded signal is emitted when + either a new object is added or when an existing object gains + one or more interfaces. The + InterfacesRemoved signal is emitted + whenever an object is removed or it loses one or more + interfaces. The second parameter of the + InterfacesAdded signal contains a dict with + the interfaces and properties (if any) that have been added to + the given object path. Similarly, the second parameter of the + InterfacesRemoved signal contains an array + of the interfaces that were removed. Note that changes on + properties on existing interfaces are not reported using this + interface - an application should also monitor the existing PropertiesChanged + signal on each object. + + + Applications SHOULD NOT export objects that are children of an + object (directly or otherwise) implementing this interface but + which are not returned in the reply from the + GetManagedObjects() method of this + interface on the given object. + + + The intent of the ObjectManager interface + is to make it easy to write a robust client + implementation. The trivial client implementation only needs + to make two method calls: + + + + org.freedesktop.DBus.AddMatch (bus_proxy, + "type='signal',name='org.example.App',path_namespace='/org/example/App'"); + objects = org.freedesktop.DBus.ObjectManager.GetManagedObjects (app_proxy); + + + + on the message bus and the remote application's + ObjectManager, respectively. Whenever a new + remote object is created (or an existing object gains a new + interface), the InterfacesAdded signal is + emitted, and since this signal contains all properties for the + interfaces, no calls to the + org.freedesktop.Properties interface on the + remote object are needed. Additionally, since the initial + AddMatch() rule already includes signal + messages from the newly created child object, no new + AddMatch() call is needed. + + + + + The org.freedesktop.DBus.ObjectManager + interface was added in version 0.17 of the D-Bus + specification. + + + @@ -2993,35 +3392,10 @@ - Messages may have a DESTINATION field (see ). If the - DESTINATION field is present, it specifies a message - recipient by name. Method calls and replies normally specify this field. - - - - Signals normally do not specify a destination; they are sent to all - applications with message matching rules that - match the message. - - - - When the message bus receives a method call, if the - DESTINATION field is absent, the call is taken to be - a standard one-to-one message and interpreted by the message bus - itself. For example, sending an - org.freedesktop.DBus.Peer.Ping message with no - DESTINATION will cause the message bus itself to - reply to the ping immediately; the message bus will not make this - message visible to other applications. - - - - Continuing the org.freedesktop.DBus.Peer.Ping example, if - the ping message were sent with a DESTINATION name of - com.yoyodyne.Screensaver, then the ping would be - forwarded, and the Yoyodyne Corporation screensaver application would be - expected to reply to the ping. + Applications may send unicast messages to + a specific recipient or to the message bus itself, or + broadcast messages to all interested recipients. + See for details. @@ -3455,20 +3829,122 @@ Message Bus Message Routing + + + Messages may have a DESTINATION field (see ), resulting in a + unicast message. If the + DESTINATION field is present, it specifies a message + recipient by name. Method calls and replies normally specify this field. + The message bus must send messages (of any type) with the + DESTINATION field set to the specified recipient, + regardless of whether the recipient has set up a match rule matching + the message. + + + + When the message bus receives a signal, if the + DESTINATION field is absent, it is considered to + be a broadcast signal, and is sent to all + applications with message matching rules that + match the message. Most signal messages are broadcasts. + + + + Unicast signal messages (those with a DESTINATION + field) are not commonly used, but they are treated like any unicast + message: they are delivered to the specified receipient, + regardless of its match rules. One use for unicast signals is to + avoid a race condition in which a signal is emitted before the intended + recipient can call to + receive that signal: if the signal is sent directly to that recipient + using a unicast message, it does not need to add a match rule at all, + and there is no race condition. Another use for unicast signals, + on message buses whose security policy prevents eavesdropping, is to + send sensitive information which should only be visible to one + recipient. + + - FIXME + When the message bus receives a method call, if the + DESTINATION field is absent, the call is taken to be + a standard one-to-one message and interpreted by the message bus + itself. For example, sending an + org.freedesktop.DBus.Peer.Ping message with no + DESTINATION will cause the message bus itself to + reply to the ping immediately; the message bus will not make this + message visible to other applications. + + + Continuing the org.freedesktop.DBus.Peer.Ping example, if + the ping message were sent with a DESTINATION name of + com.yoyodyne.Screensaver, then the ping would be + forwarded, and the Yoyodyne Corporation screensaver application would be + expected to reply to the ping. + + + + Message bus implementations may impose a security policy which + prevents certain messages from being sent or received. + When a message cannot be sent or received due to a security + policy, the message bus should send an error reply, unless the + original message had the NO_REPLY flag. + + + + Eavesdropping + + Receiving a unicast message whose DESTINATION + indicates a different recipient is called + eavesdropping. On a message bus which acts as + a security boundary (like the standard system bus), the security + policy should usually prevent eavesdropping, since unicast messages + are normally kept private and may contain security-sensitive + information. + + + + Eavesdropping is mainly useful for debugging tools, such as + the dbus-monitor tool in the reference + implementation of D-Bus. Tools which eavesdrop on the message bus + should be careful to avoid sending a reply or error in response to + messages intended for a different client. + + + + Clients may attempt to eavesdrop by adding match rules + (see ) containing + the eavesdrop='true' match. If the message bus' + security policy does not allow eavesdropping, the match rule can + still be added, but will not have any practical effect. For + compatibility with older message bus implementations, if adding such + a match rule results in an error reply, the client may fall back to + adding the same rule with the eavesdrop match + omitted. + + + Match Rules - An important part of the message bus routing protocol is match - rules. Match rules describe what messages can be sent to a client - based on the contents of the message. When a message is routed - through the bus it is compared to clients' match rules. If any - of the rules match, the message is dispatched to the client. - If none of the rules match the message never leaves the bus. This - is an effective way to control traffic over the bus and to make sure - only relevant message need to be processed by the client. + An important part of the message bus routing protocol is match + rules. Match rules describe the messages that should be sent to a + client, based on the contents of the message. Broadcast signals + are only sent to clients which have a suitable match rule: this + avoids waking up client processes to deal with signals that are + not relevant to that client. + + + Messages that list a client as their DESTINATION + do not need to match the client's match rules, and are sent to that + client regardless. As a result, match rules are mainly used to + receive a subset of broadcast signals. + + + Match rules can also be used for eavesdropping + (see ), + if the security policy of the message bus allows it. Match rules are added using the AddMatch bus method @@ -3528,6 +4004,43 @@ path match is path='/org/freedesktop/Hal/Manager' + path_namespace + An object path + + + Matches messages which are sent from or to an + object for which the object path is either the + given value, or that value followed by one or + more path components. + + + + For example, + path_namespace='/com/example/foo' + would match signals sent by + /com/example/foo + or by + /com/example/foo/bar, + but not by + /com/example/foobar. + + + + Using both path and + path_namespace in the same match + rule is not allowed. + + + + + This match key was added in version 0.16 of the + D-Bus specification and implemented by the bus + daemon in dbus 1.5.0 and later. + + + + + destination A unique name (see ) Matches messages which are being sent to the given unique name. An @@ -3537,24 +4050,99 @@ arg[0, 1, 2, 3, ...] Any string Arg matches are special and are used for further restricting the - match based on the arguments in the body of a message. As of this time - only string arguments can be matched. An example of an argument match + match based on the arguments in the body of a message. Only arguments of type + STRING can be matched in this way. An example of an argument match would be arg3='Foo'. Only argument indexes from 0 to 63 should be accepted. arg[0, 1, 2, 3, ...]path Any string - Argument path matches provide a specialised form of wildcard - matching for path-like namespaces. As with normal argument matches, - if the argument is exactly equal to the string given in the match - rule then the rule is satisfied. Additionally, there is also a - match when either the string given in the match rule or the - appropriate message argument ends with '/' and is a prefix of the - other. An example argument path match is arg0path='/aa/bb/'. This - would match messages with first arguments of '/', '/aa/', - '/aa/bb/', '/aa/bb/cc/' and '/aa/bb/cc'. It would not match - messages with first arguments of '/aa/b', '/aa' or even '/aa/bb'. + + Argument path matches provide a specialised form of wildcard matching for + path-like namespaces. They can match arguments whose type is either STRING or + OBJECT_PATH. As with normal argument matches, + if the argument is exactly equal to the string given in the match + rule then the rule is satisfied. Additionally, there is also a + match when either the string given in the match rule or the + appropriate message argument ends with '/' and is a prefix of the + other. An example argument path match is arg0path='/aa/bb/'. This + would match messages with first arguments of '/', '/aa/', + '/aa/bb/', '/aa/bb/cc/' and '/aa/bb/cc'. It would not match + messages with first arguments of '/aa/b', '/aa' or even '/aa/bb'. + + This is intended for monitoring “directories” in file system-like + hierarchies, as used in the dconf configuration + system. An application interested in all nodes in a particular hierarchy would + monitor arg0path='/ca/example/foo/'. Then the service could + emit a signal with zeroth argument "/ca/example/foo/bar" to + represent a modification to the “bar” property, or a signal with zeroth + argument "/ca/example/" to represent atomic modification of + many properties within that directory, and the interested application would be + notified in both cases. + + + This match key was added in version 0.12 of the + D-Bus specification, implemented for STRING + arguments by the bus daemon in dbus 1.2.0 and later, + and implemented for OBJECT_PATH arguments in dbus 1.5.0 + and later. + + + + + + arg0namespace + Like a bus name, except that the string is not + required to contain a '.' (period) + + Match messages whose first argument is of type STRING, and is a bus name + or interface name within the specified namespace. This is primarily intended + for watching name owner changes for a group of related bus names, rather than + for a single name or all name changes. + + Because every valid interface name is also a valid + bus name, this can also be used for messages whose + first argument is an interface name. + + For example, the match rule + member='NameOwnerChanged',arg0namespace='com.example.backend' + matches name owner changes for bus names such as + com.example.backend.foo, + com.example.backend.foo.bar, and + com.example.backend itself. + + See also . + + + This match key was added in version 0.16 of the + D-Bus specification and implemented by the bus + daemon in dbus 1.5.0 and later. + + + + + + eavesdrop + 'true', 'false' + Since D-Bus 1.5.6, match rules do not + match messages which have a DESTINATION + field unless the match rule specifically + requests this + (see ) + by specifying eavesdrop='true' + in the match rule. eavesdrop='false' + restores the default behaviour. Messages are + delivered to their DESTINATION + regardless of match rules, so this match does not + affect normal delivery of unicast messages. + If the message bus has a security policy which forbids + eavesdropping, this match may still be used without error, + but will not have any practical effect. + In older versions of D-Bus, this match was not allowed + in match rules, and all match rules behaved as if + eavesdrop='true' had been used. + @@ -3587,17 +4175,27 @@ . - [FIXME the file format should be much better specified than "similar to - .desktop entries" esp. since desktop entries are already - badly-specified. ;-)] Service description files have the ".service" file + Service description files have the ".service" file extension. The message bus will only load service description files ending with .service; all other files will be ignored. The file format is similar to that of desktop + url="http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html">desktop entries. All service description files must be in UTF-8 encoding. To ensure that there will be no name collisions, service files must be namespaced using the same mechanism as messages and service names. + + + + [FIXME the file format should be much better specified than "similar to + .desktop entries" esp. since desktop entries are already + badly-specified. ;-)] + These sections from the specification apply to service files as well: + + + General syntax + Comment format +
Example service description file @@ -3692,11 +4290,221 @@ The environment variable should have precedence over the root window property. - - [FIXME specify location of .service files, probably using - DESKTOP_DIRS etc. from basedir specification, though login session - bus is not really desktop-specific] - + The address of the login session message bus is given in the + DBUS_SESSION_BUS_ADDRESS environment variable. 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). + + + + + + [FIXME specify location of .service files, probably using + DESKTOP_DIRS etc. from basedir specification, though login session + bus is not really desktop-specific] + + System message bus