[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sieve directions (was Re: compilation in separate directory fails)
From: |
Sergey Poznyakoff |
Subject: |
Re: sieve directions (was Re: compilation in separate directory fails) |
Date: |
Tue, 05 Nov 2002 15:53:32 +0200 |
Hello,
> The plan was to use our address parser, rather than theirs. Anything
> that's not needed to compile can just be removed.
OK.
> 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:
Yes, it is reasonable. I plan to split sieve into the library
(libsieve) and the application itself, the library being LGPL and the
app being GPL. The library will reside in libsieve directory (the
sv* sources go there). Possibly we could avoid creating new directory
for the application by creating a new branch in sieve/. This will
allow both versions to coexist for a certain time. When the GNU sieve
is ready, we will simply make this branch the head one.
> 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 guess putting them to examples/ is a good idea.
> Ok, back to work for me.
>
> Cheers!
Thanks for the directions!
Regards,
Sergey