org.freedesktop.DBus.ReloadConfig not sending a reply
Havoc Pennington
hp at redhat.com
Mon Oct 31 15:58:16 PST 2005
On Mon, 2005-10-31 at 10:40 +0100, Julien PUYDT wrote:
> Sjoerd Simons a écrit :
> > I noticed that org.freedesktop.DBus.ReloadConfig doesn't send out a reply.
> > From what i understand from dbus, methods should always send out a reply so
> > that's a little odd?
>
> No, the methods may be no_reply.
>
I don't think that's what I intended. The *method call* can be no_reply,
but if a method call is not no_reply then the reply (error or success)
is intended to be mandatory. Method call != method, i.e. the client
determines whether it wants a reply as a flag in each separate call. If
the client wants a reply the server must always send one.
Otherwise, there's no way for a synchronous method call to know when
it's OK to stop blocking.
I think the patch is right in spirit (I didn't check the details)
> I didn't check what the code does, but I know for gnomemeeting I have
> quite a few methods which don't reply anything because the answer, if
> any, will take way too long to come. In that case I use signals :
> perhaps a "ConfigReloaded" signal would do the trick ?
In this case you should have the method return no data, but you should
still send a reply message so the caller knows to stop blocking. Unless
the caller sets the no reply flag on the method call message.
In other words the reply is a way to say "OK, I got the method call and
processed it" - if the caller doesn't need to know that (e.g. it's
async), it can set the no reply flag.
Reply message is different from having reply data (return values).
Another reason to use a binding is that writing raw libdbus code will
lead you to get these details wrong...
Havoc
More information about the dbus
mailing list