Errors and the introspection format
hp at redhat.com
Mon Feb 20 16:04:53 PST 2006
On Mon, 2006-02-20 at 22:20 +0000, Robert McQueen wrote:
> 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.
Agree with all of your mail except this part, I thought NoReply was just
intended to change how the caller code was generated. That's what the
glib bindings use it for, they just generate a proxy method that has no
return value or error return, and that sets the no reply flag on the
I looked at what the spec says for the NoReply annotation and even I
can't figure out what it means ;-) so I guess we need to fix that.
I still don't know on what basis a callee/server would decide whether
the caller/client should use a "no reply" or "async" call vs. sync ... I
can't think of an example where the callee/server has a clue what to
Say the server has a lengthy operation, like "compute PI to a zillion
digits", a GUI client will probably want to use an async call to avoid
locking up, but a command line client will probably want to use a
blocking call. How would the server know which to pick?
Or say the server has a call like "void LaunchMusicPlayer()", the client
may not want to handle an error in launching it - in which case it may
as well use noreply - but the client might want to display a dialog if
the server crashes before executing the call, or might want to display
any returned exceptions - and then the client can't use noreply. Again
the relevant thing is whether the client wants a reply, not any property
of the interface/server/callee.
More information about the dbus