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

[Milian Wolff]

On Thursday 15 December 2011 20:35:58 Volker Krause wrote:
> 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.

So, any idea on how to get this going? My hack-around with the commented-out 
throw made me able to read my mail while I had no inet connection the last 
days. If this is potentially hazardous, we should really do what you propose, 
but where should this be put to? Do we have to go through all uses of 
itemretriver / itemfetchhelper to find out where to add said "failsafe" 
property?

> 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.

Can you point me to a place where this is actually used? 

> 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.

Yes, I'll try to add a check for my stuff as well, cheers.

> 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.

The problem with these invalid entries is that they are never displayed, since 
they have no data at all, esp. no header etc.

So, should I 

a) make kmail display them anyways?
b) delete them after all?
c) ... ?

thanks! take care
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111221/5e1ddb7d/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/