Re: Server-Based Splitting?

[Simon Josefsson <jas@pdc.kth.se>]

Jochen_Hayek@ACM.org writes:

>     SJ> But we can write nnimap split functions that uses server-side
>     SJ> splitting, but they will be server specific and won't all have the same
>     SJ> syntax.
> 
> Actually I don't see the point
> trying to implement an abstraction / encapsulation layer,
> that isn't really an abstraction
> -- I mean `abstracting of concrete details of concrete lower
> layers'.

No, this wasn't my point. For a abstract "one-syntax-for-all-servers"
mail filter there is the nnimap mail filtering today.

Server side splitting with procmail (or "plussing" etc) is
client-independent and IMHO is the best way of doing this (if it's
possible).

But there is server side mail filtering where the rules are given by
the client. Theese can't be server-independent because all servers use
different syntax/semantic for specifying mail filters.

If we want to support server side mail filtering by having the client
supply the server with filter rules, we need to have support for each
different method of doing this.

The idea I had would be to do something like:

(setq nnimap-split-rule 'nnimap-split-cyrus)
(setq nnimap-split-cyrus-rules "SIEVE COMMANDS ...")

Or 

(setq nnimap-split-rule 'nnimap-split-exchange)
(setq nnimap-split-exchange-rule "flowchartsplitdiagram.doc")

Or whatever.

> And because any future IMAP extension in the area of mail splitting
> is quite unlikely to match gnus ideas of how those rules
> should be specified, why just not do it as close to the server as possible
> and as efficient as possible.

I agree.

But I think there is a need of support all three mail filter paradigms
available, server-side splitting (procmail, plussing, etc),
client-side splitting (what we have today) and
server-side-specified-by-client splitting (what we are discussing).

/s