[Evolution-hackers] Issues with new EBook dbus implementation

[Alexander Larsson <alexl redhat com>]

I needed the most recent eds to test the folks eds backend, and I picked
up the new dbus EBook APIs. Unfortunatelly that seemed to be completely
broken for me (evolution contacts hanged, test-self in the tests
hanged), so I have debugged it. Turns out that it was sending a dbus
signal like get_contact_done but the code was expecting a
getContact_done signal.

Patches to fix this at:
https://bugzilla.gnome.org/show_bug.cgi?id=651147

However, looking at the internals made me worry about some details.

First of all, gdbus_proxy_call_sync() when called on the main thread
will recurse the mainloop. This (mainloop recursion) is considered very
bad practice and should only be done very explicitly. Unchecked
reentrancy like this can cause all sorts of weird problems and was the
main reason bonobo failed.

For instance, a single call to a sync EBook API can reenter the
mainloop, handle a gdk destroy event and close the main window of your
app, or call *any* other apis in the whole app. To correctly handle this
all internal state must be consistent and after return from any sync
call you must assume all internal state may have changed. This is not
something most apps can do, especially when this is happening in some
lowlevel addressbook api call.

Furthermore, I don't see why this is required at all. GDBus (for this
very reason, amongst others) does all its i/o in a worker thread and
should be able to pump messages even while the main thread is blocking.

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()).