Question about Sieve and "filters"

[Michael Fair]

> > 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;
> >
> >
>
> Maybe:
>
> filter :myfilter {
>  switch :result {
>   case A:
>          {
>           do_something_A_specific;
>          }
>   case B:
>          {
>           do_something_B_specific;
>           break;
>          }
>   default:
>           {
>            do_something_default_example_stop;
>            break;
>          }
>  }
> }
>
> ^ I must admit that I love switch/case :)

THe case switch works for me but that is yet one more proposal
to bring up.

If we count this one, so far we have three proposals on the table
"filter modules", "result placeholder", and "case statement"
each which should be discussed separately since neither are
dependent on each other.  I've got no problem dicussing them
we should jsut bring them up on their own threads.

I particularly only care about modules and "result" since
those specifically address my needs.  A case statement would
be nice except that I find the most useful comparisons aren't
"eq" but more substring matches and relative comparators.
This essentially turns a case statement into an elsif of a
different color and IMHO makes a case statement not very useful
in practice for this kind of processing.

For instance, you can't say:
switch result :value
{
case "le" "-30":
case "ge" "5":
case :contains "substr":
}

which to me makes if/elsif/else, while cumbersome, the most
useful in practice.

> Usually you say in the script which are 'required' extensions, those would
> be constructed nicely into "variables" too :/ It would not be too complex
> since usually scripts are written by client-software and not by end-user
> ... and usually programmers write those clients :-)
>
> maybe ifmodule ?! but then client needs to know what that specific module
> and we would need to "reserve" module-names / "names to refer", argh.

The only required extension is "filter".  Module names are parameters
to "filter" and will vary from site to site.  I decided to drop the
whole concept of trying to announce which modules were available.  It
is completely unreliable, overly cumbersome, and doesn't add that much
value for the costs involved.  The only real purpose it would serve
is to allow script GUI composers to provide a drop down of the supported
filters but in the end you still need to account for bad names so you
haven't bought yourself much.

Instead I'm proposing that:
filter :badmodule
return "NIL" and be treated as a noop in terms of modifying the
actual email.  I'll have to figure out some decent behavior for
fileinto "NIL"; since fileinto filter :fileinto; could result in
"NIL" if the "fileinto" module was unavailable.


I completely agree that DSO's would make for a nice implementation
of managing the modules.

-- Michael --


> I am going to be nuts soon if I am not already ;)