[imapfilter-devel] IMAPFilter 2.1

[Lefteris Chatzimparmpas]

On Wed, Nov 25, 2009 at 04:10:11PM -0500, William Faulk wrote:
> On 11/25/2009 03:33 PM, Lefteris Chatzimparmpas wrote:
>>
>> currently imapfilter's IDLE returns as soon as a new
>> message has been reported by the mail server, otherwise it will
>> basically wait forever
>
> True.  I was giving a complicated example.  If it pops out at the first  
> EXISTS, then that makes it that much easier.  You still need to watch  
> for untagged EXISTS and EXPUNGEs while not in IDLE, though.

Currently imapfilter doesn't care for those, it doesn't store them and
thus doesn't give the capability to the user to see what has changed,
since basically the user always does a search to what has changed.

And this makes more sense since imapfilter is not some GUI user agent
that probably should record such untagged responses in order to present
to the user changes in the GUI.

For just filtering based on searching I believe what imapfilter does is
pretty much enough.

> Ultimately, what I'm getting at is that it would be nice to be able to  
> run filters against only newly arrived messages, which would  
> significantly optimize runtime and network bandwidth.  This is actually  
> what my further comments were going to be about.  I'll start a new 
> thread.

You can always get only recent/new/unread/etc. messages when filtering
and it will be quite fast as long as you don't use regex matching with
the match_*() methods.

That's one of the things that should be optimized in a next relase
though; being able to do some kind of pipelining in order to match on
what was already matched with some other filter (eg. is_recent() or
recorded messages by IDLE, and so on).  This will benefit mainly the
match_*() methods, since it will be more network friendly.

So then you might have filters like:

	account.mailbox:is_recent():is_smaller(5000):match_header('foo')

Thus fetch only those that are recent, and from those recent, the ones
that are small enough.  This would benefit also the rest of searching in
general at least it would be more friendly to the server.

To be seen... Send more ideas, as some of those came up after a user
contacted me in private wanting to do something in the lines of what I
just explained.