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

[Sergey Poznyakoff]

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