On Fri, 2011-05-27 at 16:49 +0200, Milan Crha wrote: > Main reason for this change was a fact that some operations may timeout > on a DBus call, because backend wasn't able to finish the requested > operation in a given time (defined by DBus; later with some workaround > on eds side). It could timeout either because remote server (the one > backend was talking to) didn't respond on time (used to happen most > often with evolution-mapi, for example) or because the backend itself > was busy with other stuff and the requested operation waited for its > processing. New API has this divided into two steps, the first is > invoking the function by simple DBus call, the second is waiting for the > done signal associated with this call.
Btw, I was thinking about this. Is this kind of solution really needed? I mean, its easy to bump the timeout for the async ops, and i think the current maximum dbus timeout is six hours. Are there actual correct evolution operations that we expect to take more than six hours to complete? _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers