Errors and the introspection format

Havoc Pennington hp at
Sun Feb 19 21:27:26 PST 2006

Argh, my reply bounced.

Here it is cut-and-pasted in, with some cleanups ;-)

On Sun, 2006-02-19 at 20:22 +0000, Daniel P. Berrange wrote:
> There alreayd is an annotation
>   org.freedesktop.DBus.Method.NoReply
> I'm not clear on how this is supposed to be used in pratice though. As
> a service, I can annotate a method with this, and not send any return
> message, but if a client isn't looking for the annotation, it'll hang
> forever.

Here's how it is supposed to work right now:

 - the intent is that the NoReply annotation affects only _client_ 
   code, not server code.

 - servers should work as follows:
   - if the "no reply" hint is set in DBusMessage, the server 
     can send a reply if it wants, but need not
   - otherwise, the server _must_ send a reply, either 
     an empty success reply, a return value, or an error

 - this annotation should not appear in introspection results. 
   it's not a property of the interface/server, it's a property 
   of the generated code desired by the app programmer on the client 

In other words, "no reply" is just an optimization; if a client intends
to "fire and forget" it can set this hint, and then the server doesn't
have to bother replying. DBusConnection and the bus itself also don't
have to worry about the timeout stuff. (the bus is keeping track of
messages with pending replies, for timeouts and for security, so this
overhead can be skipped if the client doesn't care about a reply.)

Looks like it's somewhat confusing to use the same file format for
introspection data and code generation. Maybe we can find a way
to make that clearer, e.g. we could split "interface", "client
annotations" and "server annotations" perhaps into distinct XML

But better docs may be enough of a solution.


More information about the dbus mailing list