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

List:       kmail-devel
Subject:    Re: kmail usability with IMAP
From:       Zack Rusin <zack () kde ! org>
Date:       2002-08-03 4:23:27
[Download RAW message or body]

On Friday 02 August 2002 23:34, Anthony Moulen wrote:
> Sorry to swap destination on this (it was to kde-devel) but this
> seems like the more appropriate list and I was away from my mail for
> the last week and just now am catching up.  I would like to help if I
> can on a IMAP caching feature.  I would personally prefer something
> in line with what Microsoft does with Outlook (actually Notes allows
> for this as well) and be able to cache individual IMAP folders
> instead of the entire IMAP mail store.  I have over 2 gig of email on
> my email server.  Most of this is really old archives of mail from
> previous jobs and school.  I never want to see this mail sitting on
> my laptop.  I do occassionly have to go digging around it for some
> old file or piece of information.  I want something like my Inbox and
> a few key folders besides cached for offline use.

First of all thanks for offering help but I think I and Rob will do just 
fine as far as coding goes, what we could use would be testers :) You 
see caching on a per-folder basis is not a problem. We have to check 
the uidvalidity response anyway for each one of them. The problem with 
caching IMAP messages is of course the fact that servers are permitted 
to change UID of messages in order to keep them in ascending order. So, 
if uidvalidty field is OK, then all we do is:
tag1 UID FETCH <lastSeenMessage+1>:* <descriptors> 
to get the new messages and 
tag2 UID FETCH 1:<lastSeenMessage> FLAGS 
to update flags on the old ones. But we have a problem as soon as 
uidvalidity changes. The 'Internet Draft: IMAP4 Disconnected Access' 
suggests to use other message fields to create unique identifiers other 
than uid's for cached messages, requires mua's to clean the queue from 
all operations if uid's change between sessions and suggests presenting 
a warning message to the users if this happens. In any case, I and Rob 
will have do some brain-storming after 3.1 is released to come up with 
some clean solutions.

Thanks,
Zack 

-- 
Montana -- At least our cows are sane! 

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]