sieve directions (was Re: compilation in separate directory fails)

[Sam Roberts]

Wrote Sergey Poznyakoff <address@hidden>, on Mon, Nov 04, 2002 at 12:55:30PM 
+0200:
> I've fixed most of the *.y files, except sieve/gram-sieve.y which
> isn't used anyway. The file sieve/addr.y contains 12 rules which
> are never reduced. Sam, do you have any plans on using them, or
> they can be just removed? The rules in question are:

[snip]

The plan was to use our address parser, rather than theirs. Anything
that's not needed to compile can just be removed.

> Also, I would like to start rewriting sieve to make it entirely
> GPL'ed. Any objections?

Since almost all the code in sieve/ is from CMU, I think rewriting in
place doesn't make much sense, there wouldn't be anything left but
what I wrote.

I'd suggest making a GNU sieve directory, and start implementing a new
sieve there, pull anything over that I wrote that you find useful, all
LGPL:

sieve.c
svcb.c
svctx.c
svfield.c
svfield.h
sv.h
svutil.c

I am fine with reassigning sieve.c as GPL, since its the main for the
sieve executable. Sieve can be used as a library (even though its not
being built into a library now), so the sv*.[ch] are under the LGPL, to
allow that. I'm not sure if you meant a GPL sieve library. I guess if
you write a sieve library, you can make it GPL, and people wanting a
non-encumbered library can use CMU sieve+mailutils. 

The 3 things in sieve/ (CMU sieve, the sv*.[ch] implementation of the
callbacks, and the sieve.c executable) could be seperated from each
other, if this code is to keep developing.

At work, I've modified sieve to take a poll interval, and I use it
fetchmail-like to download and filter my mail. I should commit this,
I've just been too busy lately, and I haven't actually made it become a
daemon and use syslog, the obvious next step.

I should also post to the cmu-cyrus group to tell them that their sieve
is useable standalone with GNU mailutils, I'd been waiting until it was
solid (I haven't tested the mail redirecting much).

However, if you make a GNU sieve, which could be fun, then I would
suggest that a form of the sv callbacks useable with CMU-sieve be
packaged in examples, or somewhere, as an example of how to use
mailutils with CMU sieve. Or maybe I should try and get that code
packaged with the standalone cmu-sieve as an  example of how to use
CMU-sieve with mailutils?

I think one of the most valuable things about sieve is as a use-case for
mailutils. The mailutils code originated in server daemons, and was then
morphed to work for command-line clients. Most of the time I spent on
sieve was actually working on the mailutils API to make it work for a
daemon that was a *client*, not a server. When you do that, you find the
problems (like mu_error() printing to stdio, the not-very-flexible
client-authentication framework, and the inability to dotlock a
mailspool).

Ok, back to work for me.

Cheers!
Sam

-- 
Sam Roberts <address@hidden>