Draft: URI syntax to identify D-Bus resources
Motivation
The current specification offers "Server Addresses", to allow description of listenable and connectable addresses. While this description is useful to configure basic connection details, it doesn't offer any way to identify a particular D-Bus resource, such as a service, an interface or an object. Furthermore, it doesn't conform with the standard RFC3986 URI syntax, which challenges applications with different mechanisms when they need to refer to heterogeneous resources.
Proposal
Introduce a URI syntax for dbus, with the general form:
dbus[+transport]://[authority][path][?extraparameters]A D-Bus URI doesn't replace a D-Bus address: it doesn't offer any "listenable" options. Also, a URI doesn't have multiple addresses fallback mechanism. They serve different purposes and are complementary.
Examples:
-
dbus:///system & dbus:///session Identify the well-known buses (the mechanism to locate the address is as defined in "Well-known Message Bus Instances")
-
dbus+tcp://myserver:3289 (either ipv4 or ipv6?))
(launchd & systemd should be covered by dbus+unix)
(autolaunch transport is not covered by the URI syntax at this point)
-
dbus:///session?name=org.freedesktop.Service&path=/org/freedesktop/Path&interface=org.freedesktop.Interface
Identify the
org.freedesktop.Service&/org/freedesktop/Path&org.freedesktop.Interfaceon the session bus.
The name parameter may be a well-known name or a unique name (a bus name).
Extra parameters
Extra parameters can be added to URIs as part of the query string (the part following "?"). URIs understand the extra parameters shown below. Any others are passed unmodified through to the back end. Note that parameter values must be URI-escaped.
| Name | Transport | Meaning |
|---|---|---|
| guid | all | The server GUID |
| name, path, interface, property or method or signal | all | D-Bus resource identification |
| noncefile | tcp | File location containing the secret |
| argv0, argv1... | unixexec | Program arguments |