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

List:       kmail-devel
Subject:    In progress work for 3.2
From:       Don Sanders <sanders () kde ! org>
Date:       2003-09-02 10:52:44
[Download RAW message or body]

Hi guys,

In n7y Till and I discussed what needs to be done for asynchronous 
client side imap filtering with optional body downloading.

As a result of this discussion I'm inprogress coding two new classes. 
The first MessageProperty is a class with static methods that 
enumerate the properties that are desirable to set/get for all 
messages without bloating KMMsgBase or KMMessage with additional 
member variables and methods. These properties are 
  filtering // determines if the message is currently being filtered
  filterFolder // the folder the message is intended to be moved to
    once filtering is finished.
  transferInProgress // determines if the message is currently 
     being transferred.
  complete // determines if the complete message has been loaded

I would like to port the KMMessage transferInProgress logic (which is 
pretty simple) over to this class as that will allow incomplete 
messages (KMMsgBase's) to be marked as being transferred which is 
probably a good idea for asynchronous filtering with optional body 
downloading support. I would also like to port filter action message 
moving over to using this MessageProperty class as the current filter 
message moving filter logic is pretty twisted, and using 
MessageProperty would eliminate the need to make the move action the 
last in the list of actions.

The second class is ActionScheduler, this is a class that allows 
chained asynchronous application of filters/actions to be applied to 
a list of messages, I also plan/hope it will have more sane temporary 
folder opening logic than the current approach.

I've also made some extensions to KMFilterAction and a small one to 
KMFilter to allow asynchronous actions, and actions that optionally 
don't require a body part i.e. a complete message.

Due to the difficult nature of the work I don't intend to port the 
current use of filters in the pop account and sent mail code over to 
these classes. So basically this ActionScheduler class shouldn't 
change the current flow of execution of KMail very much at all, 
except I intend to port the manually applying filters code over to 
use ActionScheduler and to use them for client side imap filtering.

The action scheduler may also provide a path to extend the current 
imap implementation with disconnected imap support, including a 
variety of body caching strategies, and if filteractions are made for 
copy, move, and delete operations for more responsive application of 
these operations on multiple messages. (Note delete and copy 
filteractions don't have to be registered and hence appear in the 
filter dialog)

I hope to send a patch containing the MessageProperty and 
ActionScheduler soon but it probably won't happen until after this 
weekend. I'm doing this work in parallel with my html composition 
work, and in addition to that I'm investigating techniques for 
multipart/related html mail support. I've update the 3.2 features 
page to indicate this.

That's all just thought it would be nice to let the list know what I'm 
working on with a hope to get done by 3.2

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