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

List:       kmail-devel
Subject:    Re: Question: Why does KMFilterActionMove::process()
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-04-26 17:57:36
[Download RAW message or body]

Don Sanders wrote:
> 
> On Thursday 26 April 2001 07:11, Marc Mutz wrote:
> > Hi!
> >
> > I don't understand the following code snipped in
> > KMFilterActionMove::process() (kmfilteraction.cpp):
> >
> > int KMFilterActionMove::process(KMMessage* msg, bool&stopIt)
> > {
> >   if (!mDest) return 1;
> >   KMFilterAction::tempOpenFolder(mDest);
> >   if (msg->parent())  // <===============
> >     return 0;
> >   if (mDest->moveMsg(msg) == 0)
> >     return 0; // ok, added
> >   else {
> >     kdDebug() << "KMfilteraction - couldn't move msg" << endl;
> >     stopIt = TRUE;
> >     return 2; // critical error: couldn't add
> >   }
> > }
> >
> > Why should messages be moved only when they have no parent (and when
> > _do_ message have no parent? On fetching? Aren't they children of
> > Inbox, then?
> 
> Originally KMFilterActionMove::process was applied to all messages whether
> they had parents or not. This was a problem.
> 
> OK Imagine I have two filters rules:
> 1st rule at top of list is for detecting personal mail sent directly to me
> (the most important mail!) action is transfer to a personal folder.
> 2nd rule is for handling mail sent to a mailing list, action is transfer to a
> folder created for that mailing list.
> 
> Now let's consider a mail sent to my personal address and a mailing list (and
> let's pretend that's a mailing list I don't follow to carefully like kde-cvs).
> 
> Now intutively the user would expect the rule at the top of the list to be
> highest priority and that filter rule to be used to move the message into
> my personal folder and the other filters should be ignored.
> 
> But this was not the case, instead the first filter rule would match,
> transfer the message, and then the second fitler rule would match and
> transfer the message again (which as an aside would delete the message from
> the first folder and mark it as needing compaction!). This is a problem as it
> meant personal mail cc'd to a mailing list would end up in the (seldom read)
> mailing list folder instead of my high priority personal folder.
> 
> Now orginally there was some kind of "ignore" action which meant stop after
> this rule matches, but hardly anybody understood it or used it. An
> alternative was to put the rules in reverse order (but this didn't fix the
> folder being marked for compaction problem).
> 
> Now messages with parents aren't processed. Why does that help? Because
> 1) Incoming mail has not parent, it is only put in the inbox when all filters
> have been applied and the message still has no parent folder.
> 2) When applying filters on a message, that message is first removed from its
> parent folder.
> 
> So this parent checking is useful for both fetching and applying filters.
> 
> Hope that all made sense.
<snip>

Hmm, then checking for a parent is simply like an assert(), because
KMFilter::execActions() should check for the return code. AFAICS, there
are four of them (used to be int's, now they will be enum):

-1 (GoOn):           Everything is OK, the caller of
                     execActions() is still owner of the
                     message and you should continue applying
                     filter actions.
 0 (Finished):       Everything is OK, but the caller of
                     execActions() is no longer owner.
                     Processing should stop here.
 1 (ErrorButGoOn):   There was a small error (like invalid
                     parameter). Treated the same as GoOn.
 2 (CriticalError):  There was a critical error (like "disk
                     full"). Processing should stop here.

We could replace "if( msg-parent() ) return 0;" with "assert(
msg->parent() );".
If execActions() would properly check the ret.codes, the assert() would
never fire, no?

Or is there more behind that?

Marc

-- 
Marc Mutz <Marc@Mutz.com>     http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)


_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

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