[Kde-pim] Re: Review Request: Try to recover from UIDNEXT mismatch

[Till Adam]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101142/#review2691
-----------------------------------------------------------


I think the reasoning is sound, but I was wondering about the qMax(11l, ... What's the idea behind that magic number?

- Till


On April 16, 2011, 6:12 p.m., Volker Krause wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101142/
> -----------------------------------------------------------
> 
> (Updated April 16, 2011, 6:12 p.m.)
> 
> 
> Review request for KDEPIM.
> 
> 
> Summary
> -------
> 
> In case the IMAP resource ends up with an mismatch in current and last seen UIDNEXT values, it tries to recover from that with a full re-download. With online IMAP that's not too bad, but for the offline case this can be a huge problem. So, I tried to come up with a less drastic way, but please verify my assumptions, I cannot test this scenario here, my IMAP server behaves too well.
> 
> So, my assumption is that this case can happen because of an equal amount of emails being added and deleted while we were not looking. Then the message count check passes (we still have the same amount locally and remotely), but the UIDNEXT check fails. If this is correct, and given UIDs are strictly ascending, the maximum amount of changed messages is (newUidnext - oldUidnext). So, instead of downloading everything, we now only download that many messages, since download is done by sequence number, we are guaranteed to get the newest ones and thus we cover all new messages. Deletion of the old ones is done by the subsequent flag fetch step, just as in the normal case. Does this make sense?
> 
> Thiago's problem shown in bug 259151 is slightly different, there we do the same modification locally and remotely but fail to obtain the new UID due to the server not supporting UIDPLUS and the message-id being non-unique. However, this should work with the above approach as well.
> 
> 
> This addresses bug 259151.
>     http://bugs.kde.org/show_bug.cgi?id=259151
> 
> 
> Diffs
> -----
> 
>   resources/imap/retrieveitemstask.cpp 002bb33 
> 
> Diff: http://git.reviewboard.kde.org/r/101142/diff
> 
> 
> Testing
> -------
> 
> None, unfortunately, I cannot trigger this code path here since I have no access to a non-UIDPLUS server.
> 
> 
> Thanks,
> 
> Volker
> 
>

_______________________________________________
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/