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
