[Kde-pim] offline dimap access with partially-cached or broken items in the db

[Volker Krause]

On Thursday 15 December 2011 15:08:48 Milian Wolff wrote:
> Hey all,
> 
> I have (probably due to filters and a different bug) "broken" entries in my
> database. These are rows which have no parts, or empty parts or stuff like
> this. They are not shown at all in kmail (since parts are missing and the
> queries filter them hence). It's left to be seen where these come from, but
> this is the status quo for me.
> 
> Now:
> 
> a) Any idea on how to cope with these items? Imo partially-cached or broken
> rows in the database should be purged if they cannot be retrieved from the
> agent.
> 
> b) Now, assuming we haven't yet handled a) yet, we should improve the
> current situation, because currently, when I try to access a collection
> while my machine is offline, I get:
> 
> - kmail asks akonadi to fetch items in collection, we end up in
> FetchHelper::parseStream
> - mCacheOnly is *not* set, even though we are in "offline mode" - should
> this be done?
> - itemRetriever is thus called to retrieve the data, lets look at
> ItemRetriever::exec
> - it goes through the database (so cache is still implicitly asked)
> - it finds broken or partially-cached rows and hence decides that the remote
> agent must be queried to retrieve the items
> - the agent is in offline mode (remember, no internet connection), look at
> ResourceBase::requestItemDelivery - it errors out since it is offline
> 
> result: I cannot see *any* mails while I have no online connection
> 
> my workaround now:
> 
> In fetchhelper::parseStream, comment out the
> 
>  throw HandlerException( "Unable to fetch item from backend" );
> 
> when the retriever errors-out. This *finally* makes my cached emails show
> up, even if I'm offline, yay!
> 
> The question is, how to solve this properly...
> 
> Probably a proper handling of a) would minimize the occurrence of this bug,
> yet it could still happen, that e.g. only the headers of some mails are
> cached and we want the body as well. Thus imo b) should also be improved.
> Maybe a "good enough" fix would already be to alsoways set mCacheOnly when
> in offline mode. I did not see how to access that info in the fetchhelper
> though  - ideas?

I have looked into this as well before, different causes but we also ended up 
in the (b) case there. The idea was to have a "ignore errors" mode for the 
fetch job (which is basically what you would be emulating with setting cache-
only when you are expecting errors). However, something like this must only be 
used for display or other use-cases where absolute correctness is less 
important than seeing partial results, so especially not for copy/paste, 
export, etc. So, this needs to be used with great care in client code.

I haven't gotten around to implementing this yet (the problem back then was 
fixed by asking for less (== always cached) data), but it should be pretty 
straightforward.

Regarding (a), Akonadi 1.7 (== master) has a consistency check mode that also 
performs a few cleanups/fixes already ("akonadictl fsck", output goes to 
stderr of the server atm, a D-Bus interface for it is also in place but 
currently not used yet by e.g. akonadiconsole). This could probably be 
extended to cover your case as well.

Instead of just deleting stuff, I'd feel better if we would move to a 
lost+found collection though (way less risky, can be deleted (or recovered) 
manually by the user then), that's what the current file store cleanup code 
does for example.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111215/7585dfa7/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/