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

Reply via email to