Question about Sieve and "filters"

[Michael Fair]

> On Wed, 9 Jul 2003, Michael Fair wrote:
>
> > I totally agree that end users should not be allowed to write their
> > own code.  I was thinking that sysadmins could pull from a pool of
> > well known plugins as well as write their own.  These would then
> > become valid "filters" for use in the 'filter :modulename' command
> > at that site.
> >
>
> Yes,
>
> my idea (ripped from apache):

... snip ...

> DSO is answer to this (even if it is 'slower' than static compiled) but we
> could choose either to compile static or dynamic ofcourse. So those who
> don't want to recompile always would just use dso-support.


As long as the DSO modules remain an implementation specific choice
I see no reason they couldn't be implemented this way and I'd be
really excited to see such support.  However, the main focus that
I am driving for at the moment is just getting to something that
would be somewhat well received by the time it hit an RFC draft.

While I completely agree with you that DSO modules is probably the
way to go here and would solve the problem quite nicely, I think
it's putting the cart a bit before the horse.  I haven't seen any
kind of consensus with the exception of you and I that says generic
pluggable filters are within the scope and spirit of the language.

Don't mean to curb the enthusiasm in anyway, but I just think the
conversation of "DSO versus system/fork" is still a bit premature.


> > 'filter :module' idea.  I do have one other extension to
>
> module :myspamtest I think is better.

module :myspamtest in no tells the user that it is actually
doing something.  We're looking for something that has the
feel of a verb here.  Something that says "this line will
transform the email in some way".


> then message would be re-written abit by 'myspamtest' and then:
>
> if header :matches "Spam" "Yes"
> {
>  fileinto "Spam"
> }
>
> "if it" is kinda pervertic if I say ;)
>
> We live in OO-world nowadays, we could say "if this" :-)

But Sieve isn't an OO language and "this" is meaningless
in the context of a Sieve script.  If anything "this" refers
to the email being processed not the result code/string of
a function.

While I admit "it" doesn't jive very well with most traditional
programmers, I'd ask don't knock it till you've tried it.

Further your example didn't address the whole purpose of
introducing "it" to begin with.

"it" or "result" is a placeholder variable.  Sieve has no
variables currently, and many of us have run into the insane
code duplication that comes from having to individually
enumerate the folders that you want to file your email in.

"it" or "result" is a place to put those return codes. (Or
a function to look them up for the "can't have variables purists")

So instead of:

filter :fileinto;
if header :contains ...
elsif header :contains ...
elsif header :contains ...
elsif header :contains ...
... ad nauseum ...

You have:

filter :fileinto;
fileinto result;

This simple example could probably be written as:

fileinto filter :fileinto;

But a slightly more complex script might be:

filter :spamtest
if result :value "le" "comparator-i;ascii-numeric" "-30"
{
    filter :sms
}
elsif result :value "ge" "comparator-i;ascii-numeric" "5"
{
    fileinto "spam";
}

fileinto filter :fileinto;


This script takes the same result - without modifying
the message - and builds a case statement out of it.
This kind of variable reuse is really the biggest win
I think in argument for this can't of result holding
keyword/function.

While I certainly am willing to give "it" up, "this"
doesn't replace the readability of "it".

What's wrong with "result" as a replacement for "it"
since "it" is pervertic?

-- Michael --