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

[Jeffrey Stedfast <fejj novell com>]

heh, we did that too... that was our first implementation, but the
problem is it doesn't work well for IMAP because:

1. user might not have IMAP filters enabled
2. only INBOX would ever get filtered

Jeff

On Thu, 2005-12-08 at 08:19 +0000, karllinuxtest relton ntlworld com
wrote:
> > > I wonder if we could easily go further, by
> > > a) seeing if the messages just added to the folder all have
> > > unread status
> > 
> > unfortunately this could require a full scan of the folder in question
> > in order to ascertain that information. Currently we simply request
> > STATUS (MESSAGES UNSEEN RECENT) or some such and so there's no way to
> > find out if the unseen/recent counts overlap at all because all we have
> > are counts (same problem we have in the code).
> > 
> > Querying for a full list of message flags is just not viable.
> > 
> > If the folder in question is the folder in the SELECTED state in the
> > IMAP provider (not necessarily the same as the selected folder in the
> > UI, mind you), then querying the server for a full list of flags is not
> > necessarily needed (the flags in the CamelFolderSummary for said folder
> > will contain the info we need I think, unless the \Recent message(s)
> > haven't yet had a chance to have their info's fetched... not sure), but
> > sadly this does not help us with the generic API.
> > 
> 
> Yep - I scanned around the code and it became clear that this approach was not going to be straightforward.
> 
> 
> > > b) limiting the notifications to only be issued if the
> > > folder affected is an appropriate folder for brand new
> > > mail (i.e. an 'Inbox' type folder).
> > 
> > that's how we originally did things but people wanted notification if
> > new mail arrived in any folder.
> > 
> 
> Yep - I had now realised that too.
> 
> But that has led me to think of a different approach.
> 
> How about using the existing Filtering mechanism?
> 
> I created a simple 'incoming' filter with a fairly arbitrary
> 'catch-all' type criteria, and set it to play a beep.
> And what do you know - I now get a beep when new mail
> 'arrives' (at least for my choice of backend, which is
> movemail), and don't get the beep when I am simply shuffling messages around (unread or otherwise).
> 
> Assuming incoming filtering works for all backends, then presumably this problem is effectively
> already solved - we just need a special hard-coded filter
> to produce the notifications!
> 
> Of course my assumption might be completely wrong - feel free to correct me!
> 
> Karl
> 
> -----------------------------------------
> Email sent from www.ntlworld.com
> Virus-checked using McAfee(R) Software 
> Visit www.ntlworld.com/security for more information
> 
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com