From a0c2e93fbe2094e56a7735e89e72817b5b5f64e1 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Mon, 21 Nov 2016 20:19:22 +0000 Subject: [PATCH 4/4] Spec: mostly use versioned interface and bus names Using versioned names here reinforces the advice given in . I haven't added versions to the sample parameters "com.example.tea" and "com.example.cappuccino" for methods that query information about names, on the basis that I assume they are more likely to be intended to represent an implementation than an API. Signed-off-by: Simon McVittie Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98671 --- doc/dbus-specification.xml | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 2e72c31..fbb8f25 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -1847,8 +1847,8 @@ Error names have the same naming conventions as interface names, and often contain .Error.; for instance, the owner of example.com might define the - errors com.example.MusicPlayer.Error.FileNotFound - and com.example.MusicPlayer.Error.OutOfMemory. + errors com.example.MusicPlayer1.Error.FileNotFound + and com.example.MusicPlayer1.Error.OutOfMemory. The errors defined by D-Bus itself, such as org.freedesktop.DBus.Error.Failed, follow a similar pattern. @@ -3931,7 +3931,7 @@ org.freedesktop.DBus.AddMatch (bus_proxy, - "type='signal',name='org.example.App',path_namespace='/org/example/App'"); + "type='signal',name='org.example.App2',path_namespace='/org/example/App2'"); objects = org.freedesktop.DBus.ObjectManager.GetManagedObjects (app_proxy); @@ -3973,8 +3973,8 @@ <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> - <node name="/com/example/sample_object"> - <interface name="com.example.SampleInterface"> + <node name="/com/example/sample_object0"> + <interface name="com.example.SampleInterface0"> <method name="Frobate"> <arg name="foo" type="i" direction="in"/> <arg name="bar" type="s" direction="out"/> @@ -4151,7 +4151,7 @@ unique-for-the-lifetime-of-the-bus name automatically assigned. Applications may request additional names for a connection. Additional names are usually "well-known names" such as - "com.example.TextEditor". When a name is bound to a connection, + "com.example.TextEditor1". When a name is bound to a connection, that connection is said to own the name. @@ -4173,7 +4173,7 @@ This feature causes the right thing to happen if you start two text - editors for example; the first one may request "com.example.TextEditor", + editors for example; the first one may request "com.example.TextEditor1", and the second will be queued as a possible owner of that name. When the first exits, the second will take over. @@ -4927,11 +4927,11 @@ first argument is an interface name. For example, the match rule - member='NameOwnerChanged',arg0namespace='com.example.backend' + member='NameOwnerChanged',arg0namespace='com.example.backend1' matches name owner changes for bus names such as - com.example.backend.foo, - com.example.backend.foo.bar, and - com.example.backend itself. + com.example.backend1.foo, + com.example.backend1.foo.bar, and + com.example.backend1 itself. See also . @@ -4987,7 +4987,7 @@ auto-starting, which is one form of activation. In auto-starting, applications send a message to a particular well-known name, such as - com.example.TextEditor, without specifying the + com.example.TextEditor1, without specifying the NO_AUTO_START flag in the message header. If no application on the bus owns the requested name, but the bus daemon does know how to start an activatable service for that name, @@ -5004,7 +5004,7 @@ In either case, this implies a contract documented along with the name - com.example.TextEditor for which object + com.example.TextEditor1 for which object the owner of that name will provide, and what interfaces those objects will have. @@ -5032,7 +5032,7 @@ On the well-known system bus, the name of a service description file must be its well-known name plus .service, for instance - com.example.ConfigurationDatabase.service. + com.example.ConfigurationDatabase1.service. @@ -5062,7 +5062,7 @@ # Sample service description file [D-BUS Service] - Name=com.example.ConfigurationDatabase + Name=com.example.ConfigurationDatabase1 Exec=/usr/bin/sample-configd @@ -6671,9 +6671,9 @@ A service is an executable that can be launched by the bus daemon. Services normally guarantee some particular features, for example they may guarantee that they will request a specific name such as - "com.example.Screensaver", have a singleton object - "/com/example/Application", and that object will implement the - interface "com.example.Screensaver.Control". + "com.example.Screensaver1", have a singleton object + "/com/example/Screensaver1", and that object will implement the + interface "com.example.Screensaver1.Control". -- 2.10.2