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

List:       kmail-devel
Subject:    Re: imap jobs page
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-05-04 17:46:24
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 04 May 2003 16:51, Till Adam wrote:
> On Sunday 04 May 2003 15:20, Ingo Klöcker wrote:
> > On Sunday 04 May 2003 08:54, Till Adam wrote:
> > > On Saturday 03 May 2003 18:00, Marc Mutz wrote:
> > > > As to a definition of incoming messages with IMAP: With dIMAP,
> > > > you can simply use whatever is "new" in INBOX (ie. what you
> > > > need to d/l on sync). With online IMAP, things are more
> > > > complicated: A message should be filtered either if
> > > >  1. It's in INBOX
> > > >  2. It's not \Seen
> > > >  3. It's UID is "new" to the client.
> > > > -or-
> > > >  The UIDVALIDITY changed.
> > >
> > > I have new mail in a lot of folders, not just INBOX, due to
> > > procmail running on the server.
> >
> > In this case 2. and 3. will apply.
>
> Hm, I had read that as ((1 and 2 and 3) or UIDVALIDITY changed).
>
> > > > - Enhance KMFolderCombobox to allow it to show dIMAP, but not
> > > > IMAP folders (see setShowIMAPFolders())
> > >
> > > Why are imap folders not allowed as targets anyhow? I've locally
> > > ported the filter stuff to KMCommands and things work as expected
> > > with imap folders. Is there a deeper reason for disallowing that?
> > > (Error handling becomes .... interesting ... , though. Still
> > > cleaning that up.)
> >
> > Well, the error handling is exactly the reason why IMAP folders are
> > currently not allowed as targets. With disc. IMAP this is of course
> > no problem (unless the disk is full). But with traditional IMAP
> > support messages which could not be transfered to the IMAP folder
> > have to be cached somewhere and then need to be transfered as soon
> > as the IMAP server is available again. Of course this means nothing
> > less than duplicating disc. IMAP. So we really need to merge online
> > IMAP with disc. IMAP.
>
> Ok. For local -> imap I see the point. Moving between folders on the
> same imap account should be possible though, shouldn't it? That
> doesn't require the message to be downloaded and error handling
> happens as part of normal ioslave and server operations.

Yes. But the filter configuration doesn't make any assumptions about the 
location of the messages the filter is applied on. This means that imap 
folders can only be allowed as targets if local -> imap _and_ imap -> 
imap (even between different imap accounts) work.

> Even with 
> dIMAP, it would be a shame if "put all mail from the cookie monster
> into folder foo" would require:
>
> - download the message on sync
> - move to another folder locally
> - upload on sync to new folder

But that's the way dIMAP works: Everything is done on the local copy and 
then all changes are synced with the server. What you want would 
require logging of all actions which are performed on the local copy 
and then executing these actions on the server during synchronization. 
But this could fail if the remote copy has been changed by another 
client. Therefore the dumb dIMAP approach saves us a whole lot of 
exception handling.

> On a slow link, those extra uploads hurt. Same for "mark as". For the
> header add/remove/change filter actions I see no other way, though.

Well, if the status of a message is changed then this shouldn't require 
an upload of the whole message. If this is currently the case then the 
current implementation is probably a little bit too dumb.

> I guess I agree merging the two is the way to go, but I would like to
> try and handle the above case separately, if possible.

This can be done later during the optimization. You should first try to 
implement it the dumb/easy way.

Regards,
Ingo


[Attachment #5 (application/pgp-signature)]

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