Re: Re: [evolution-patches] Possible fix for #322016

[<karllinuxtest relton ntlworld com>]

> > Hmmm, but could we not use the same technique regardless
> > of the 'IMAP - apply filters' user option?
> 
> I suppose, but we'd still have the same problem in that the filters
> wouldn't be able to tell the difference between new-for-real mail and
> new-to-the-folder-because-it-was-moved mail
> 

Indeed - but we would be no worse off than we are today.

As an aside, that implies to me that the current filtering system could filter on an imap inbox a new-to-the-folder-because-it-was-moved mail. Of course
the user may have a filter which then catches this mail
and moves it to yet another mailbox (so the user moves the
mail manually to the Inbox, and then the filter moves
it elsewhere)!

> > 
> > And since IMAP also has a user option 'check for new
> > messages in all folders' suggests that #2 is surmountable
> > as well.
> 
> not really. you need to open all folders in order to filter them, the
> check-new-mail-for-each-folder thing really only sends a STATUS command
> to get message/unread counts.
> 

Right - but my point here is that we wouldn't actually
filter (so no need to read the actual messages). Instead we
just need to hook in at the same point the system 'checks
for new mail' (by getting STATUS message/unread counts),
and if that check reveals more unread messages than
we had previously we can send our notification.

Could you point me at the code file where this check
is done (for an imap backend), and also where the
filters are initiated from. I have found my way into
e-d-s/camel, finding the filter_driver_filter routines, but
can't work out where these are called from.

Cheers
Karl

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software 
Visit www.ntlworld.com/security for more information