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

List:       kmail-devel
Subject:    Re: KMail blocks just before checking POP3 mailboxes
From:       Martijn Klingens <klingens () kde ! org>
Date:       2004-05-31 15:44:23
Message-ID: 200405311744.23825.klingens () kde ! org
[Download RAW message or body]

On Monday 31 May 2004 17:14, Ingo Klöcker wrote:
> It's in ~/.kde/share/apps/kmail/$login:@$popserver:$port where $login is
> the login name on the POP server $popserver and $port is obviously the
> port. The seenUidList is used for leaving messages on the server (in
> order to identify new unseen messages. Since you don't leave messages
> on the server you can simply clear this list. We should probably make
> sure that we don't write the seenUidList (resp. write an empty list) if
> the user doesn't leave messages on the server.

I've been thinking about this a bit when I was outside and I think this is 
only half the solution.

(For the record: for my KDE CVS account the seenUidList entry contains a 
whopping 80629 entries, which is apparently the amount of mails on that list 
since early August last year. No wonder KMail is slow...)

My proposed solution:

1. Don't write the UIDs that have been successfully deleted from the server.
   With my setup that's all the UIDs. For people who leave mail on the server
   for a limited amount of time that's the mails that have not been kept.
   Additionally, in the latter case, all mails that have been successfully
   expired will be removed.

2. Everything in #1 is only the 'ongoing' maintenance. If people access
   mailboxes from multiple clients there will still be accumulation of UIDs
   that have been removed from another client. Likewise there are all people
   like me who have collected this data over time from older KMail versions.
   Therefore my second proposal is to enumerate *ALL* mails on the server
   every once in a while (once a week?) and store that list in the
   sendUidList, discarding EVERYTHING ELSE. That way you get a list that's
   guaranteed to be clean every once in a while. The only case where this
   fails is when you restore a backup of the mail on the server, but if
   people do this at all then receiving duplicate mail does not have to be
   considered as bad per se.

-- 
Martijn
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel

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