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. _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers