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

[Jeffrey Stedfast <fejj novell com>]

On Fri, 2005-12-09 at 13:37 +0000, karllinuxtest relton ntlworld com
wrote:
> > > 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.

actually, we would... having to run filters on each folder would have a
hefty impact on performance

> 
> 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)!

indeed it could... hence why I never liked client-side imap filtering :)

> 
> > > 
> > > 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),

should be in camel/providers/imap/camel-imap-folder.c (or maybe
summary.c?)

-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com