[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdepim-users
Subject:    Re: KMail/Akonadi grief
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2019-11-12 10:56:42
Message-ID: 1966003.5rxo5GPGea () bola
[Download RAW message or body]

On Tuesday November 12 2019 10:49:23 Anders Lund wrote:

> akonadi must waiting for something that never happens

Or, more likely/accurately, it missed whatever the end condition is because it was \
doing something else.

> So what ever action is not answering needs to be fixed. Drop it, do it later, 

Not the action itself, the "waiting for it to complete". I'd hope that the Akonadi \
developers know by now which operation(s) are being waited for, and if so (and it is \
indeed a question of having missed the end condition) it should be possible to add a \
timeout and do whatever it is that an offline/online cycle does. Most likely that \
cycle just causes the blocking request to be repeated and if all goes well the end \
condition is detected this time around. But the protocol may also provide a way to \
query the status of the operation, removing the need to repeat the entire operation.

Another solution that should avoid this whole situation: let KMail read (and possibly \
delete) messages from the cache directly. I'm pretty certain that the Akonadi agents \
use library code for that which could just as well be called from KMail directly - \
after all this aspect should be the same regardless of the remote server protocol. \
With that approach, the agents only become responsible for communicating with the \
server, something that doesn't really require multitasking (each agent can have a \
single FIFO queue with requests for the server). Protection against concurrent \
database read/write ops is probably (hopefully) provided by the database backend. \
This should also make fetching messages faster or at least less expensive. Of course \
you'll still be waiting for that message that "won't fetch", but that cannot be \
avoided.

Or maybe something like that has already been implemented because I understand that \
PIM5 is much less hard on the D-Bus?

R.


[prev in list] [next in list] [prev in thread] [next in thread]