Re: [Evolution-hackers] Issues with new EBook dbus implementation
- From: Alexander Larsson <alexl redhat com>
- To: Milan Crha <mcrha redhat com>
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] Issues with new EBook dbus implementation
- Date: Mon, 30 May 2011 15:33:39 +0200
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?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]