Re: [Evolution-hackers] Issues with new EBook dbus implementation

[Alexander Larsson <alexl redhat com>]

On Fri, 2011-05-27 at 17:09 +0200, Milan Crha wrote:
> On Fri, 2011-05-27 at 13:01 +0200, Alexander Larsson wrote:
> > Secondly, why is it using a dbus signal for the done callbacks?
> > Wouldn't it be more sane to use a direct message (without expecting a
> > reply)? A signal will be sent to everyone subscribing to that signal,
> > which will be all clients talking to the EBook, not just the one that
> > requested the operation (i.e. called getContact()).
> 
> To be honest, I didn't get this fully. There is 1:1 correspondence
> between EBookClient (formerly EBook) and EDataBook, each has its DBus
> connection for the other part. The backend invokes those 'done' signals
> on a corresponding EDataBook, with its operation ID set, thus the
> receiver (though the only EBookClient) checks also the operation ID to
> know for what it got the result (and whether the operation itself wasn't
> cancelled meanwhile) and based on that finishes the operation. There
> might not be a problem you are describing above. I hope.

Ah, I see. Each client gets their own object instance in the server, and
we emit the signal on these? Then it should be ok. Although I still
think its a bit weird to use signals (a subscription based multicast
method) to implement a single callback. All that is really needed is to
save the source of the initial method and an object path and then do a
regular dbus method call for the callback.