Errors and the introspection format

[Robert McQueen]

Thiago Macieira wrote:
> But, just for sake of consistency, I'm allowing the following declaration:
> 
>   void async Frobate()
> 
> where async is #define'd to empty. This is similar to the DCOP style:
>   ASYNC Frobate()
> 
> This will make the introspection data contain the 
> org.freedesktop.DBus.Method.NoReply annotation. When generating code for 
> one such method, I'll use the "fire-and-forget" mode.

Er... an asynchronous call is not the same as not waiting for a reply.
There are three ways to call a method from the perspective of the client
side:
 * Synchronous call: We block waiting for a reply or an error from the
service, and time out if we don't get one.
 * Asynchronous call: We set up a callback in the client which gets
called when the service sends us a reply or an error, then send our
method call.
 * No reply call. We set the "No Reply" flag in our outgoing message,
send it, carry on, and if we get any reply from the service, we ignore
it anyway. There is no distinction between sync or async because we
don't care about the reply.

On the service side, we can implement methods synchronously (the method
called blocks the service process until it's generated a reply of some
sort) or asynchronously (the method is given some context which can be
stored and used later a callback to send a reply or error). This
implementation detail is orthogonal to whichever kind of method call the
client made, and the low-level library takes care of not sending the
reply message if the method call had the no reply flag set. An
optimisation in bindings might be to not bother marshalling a reply
message if the flag is set, but it's important not to confuse replying
or not with sync or async calls or implementations.

Saying "no reply" in your annotations is a hint to the caller not to
wait up for the answer, which could mean that it'll be a long time
coming, and/or that it's irrelevant (void return) anyway.

Regards,
Rob