Expand documentation of NO_REPLY_EXPECTED
authorSimon McVittie <simon.mcvittie@collabora.co.uk>
Tue, 23 Sep 2014 16:43:30 +0000 (17:43 +0100)
committerSimon McVittie <simon.mcvittie@collabora.co.uk>
Wed, 24 Sep 2014 17:07:54 +0000 (18:07 +0100)
The message type is more important than whether NO_REPLY_EXPECTED is
set, when deciding whether a reply is expected. This documents
existing practice in at least libdbus, GDBus and dbus-daemon.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75749
Reviewed-by: Thiago Macieira
doc/dbus-specification.xml

index 3276f2b..a110a08 100644 (file)
               <row>
                 <entry><literal>METHOD_CALL</literal></entry>
                 <entry>1</entry>
-                <entry>Method call.</entry>
+                <entry>Method call. This message type may prompt a
+                  reply.</entry>
               </row>
               <row>
                 <entry><literal>METHOD_RETURN</literal></entry>
               <row>
                 <entry><literal>NO_REPLY_EXPECTED</literal></entry>
                 <entry>0x1</entry>
-                <entry>This message does not expect method return replies or
-                error replies; the reply can be omitted as an
-                optimization. However, it is compliant with this specification
-                to return the reply despite this flag and the only harm 
-                  from doing so is extra network traffic.
+                <entry>
+                  <para>
+                    This message does not expect method return replies or
+                    error replies, even if it is of a type that can
+                    have a reply; the reply can be omitted as an
+                    optimization. It is compliant with this specification
+                    to return the reply despite this flag, although doing
+                    so on a bus with a non-trivial security policy
+                    (such as the well-known system bus) may result in
+                    access denial messages being logged for the reply.
+                  </para>
+                  <para>
+                    Note that METHOD_CALL is the only message type currently
+                    defined in this specification that can expect a reply,
+                    so the presence or absence of this flag in the other
+                    three message types that are currently
+                    documented is meaningless: replies to those message
+                    types should not be sent, whether this flag is present
+                    or not.
+                  </para>
                 </entry>
               </row>
               <row>
         <literal>DESTINATION</literal> field is absent, it is considered to
         be a <firstterm>broadcast signal</firstterm>, and is sent to all
         applications with <firstterm>message matching rules</firstterm> that
-        match the message. Most signal messages are broadcasts.
+        match the message. Most signal messages are broadcasts, and
+        no other message types currently defined in this specification
+        may be broadcast.
       </para>
 
       <para>
       <para>
         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
+        When a method call 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 <literal>NO_REPLY</literal> flag.
       </para>