org.freedesktop.DBus.ReloadConfig not sending a reply

[John (J5) Palmieri]

On Mon, 2005-10-31 at 18:58 -0500, Havoc Pennington wrote:
> 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

Of course this means the bindings get it wrong too :-)  I think bindings
take no reply to mean I'm not going to send a reply.

-- 
John (J5) Palmieri <johnp at redhat.com>