[Kde-pim] Q about CachedImap code

[Till Adam]

On Tuesday 06 April 2010 21:42:43 Adrian von Bidder wrote:

> Thanks for your answers.

Thanks for helping out with KMail. Please excuse me, if I'm a bit slow 
responding, my KDE spare time is extremely limited, these days :).


> It's slow going for me, since I find kmail code not too easy to read (...
> and I'm new to Qt/KDE, and it's been ages since I've used C++.)  I'll try
>  to persevere, though.  Any input appreaciated.

You've picked one of the more challenging code bases to work on. KMail is one 
of the older KDE apps, and has a lot of organically grown stuff, some of the 
code is more than 10 years old, at this point. It ain't pretty. It's a very 
rewarding thing to work on, though, used by many, many people and generally 
well behaved.
 
> In case you haven't read my previous emails: kmail currently more or less
> completely fails in terms of "ignore thread" functionality: if email comes
> into a folder between "check for new mail" runs, when that folder is not
> selected, the "ignore" flag is lost on all threads that get new mail.

I see. See below.

> I'm trying to work out the cached imap case because that's what I'm using,
> I'm not sure if the other protocols are affected or not.  I'm currently
> trying to follow the code to see how the flag is stored and, once I've seen
> that, I plan to look into how exactly kmail loads a folder.  So I'm still
>  at the reading source code stage.

Thread ignoring should be independent of the transport and storage. It happens 
at message threading time, in the headers list. That means the flags are 
updated when the folder is shown, not before, as that is the first time that a 
thread structure is built, or updated, for previously opened folders. It's 
thus not surprising that you would see nothing happening at mail check, or 
when the folder is not currently viewed. Once the flags have been updated, on 
the KMMessage objects, they are persisted to the .index files that KMail keeps 
for each folder (pre 4.5/trunk that is, where we use Akonadi). On the next 
mail check, as part of the general flags upload, those flags which can be 
written to the server are uploaded. In the case of IMAP, which only supports a 
handful of flags natively, a custom flag is used, which is kmail specific. As I 
said, I'm not sure whether we currently persist the ignored flag to the server, 
it seems like something that would be per-client, and thus more or less local. 
Arguable.

> On Tuesday 06 April 2010 09.09:21 Till Adam wrote:
> > [...] (I wrote the ignore stuff a long time
> > ago), [...]
> 
> ... and if you have ideas what could cause that bug I'd be happy.
> 
> If you look into the KDE bugzilla (#186853), the bug is by now quite old,
> with a few confirmations, and nobody who actually could do so (more)
> efficiently (than me) has stepped up :-(

There is so much to do in KMail ...

> From the way that it has been reported fixed and re-confirmed unfixed it
> appears that it's a fragile kind of thing.
> 
> > IMAP does not know this flag, so if you want to store it
> > there, it needs to be sent as a custom (kmail-specific) flag, which I
> > think we do for "to do".
> 
> There's an "$IGNORE" flag being handled, I guess that's the one.  What
> puzzles me is that the "mPermanentFlags" is not the same for every message
> (Naively, I'd expect this to be always the same for a given IMAP server.)
> I've put in some debugging output in KMFolderCachedImap::slotPermanentFlags
> to check this.  Maybe this is one part of the issue, that kmail thinks it
> can store the flag but then the IMAP server really can't?

If I remember correctly, the permanent flags are those that are persisted to 
the server, so they can still be different for each message.

Cheers,

Till

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