dovecot - Feb 2007 - sieve plugin

I'm currently looking at dovecot for a large-scale deployment.  The
requirements will almost certainly mean we would use the dovecot lda with
the sieve plugin.

The current method of distribution causes (binary distro) packaging to be
slightly awkward IMHO.  The dovecot-sieve code needs to be told where an
in-tree build of dovecot lives.  The fact that it _must_ be an in-tree
build I was considering as a bug; the dovecot-sieve build wants to access
both '.a' and '.h' files from the dovecot build but in an
out-of-tree
build these are in different places.

My first thoughts were to simply move the dovecot-sieve code into the
dovecot tree (I imagine under src/plugins/cmusieve or similar) and rework
the autoconf setup as appropriate.  This sidesteps the problem for this
case but does not help other 'third party' dovecot plugins.

If however a simple plugin build environment were to exist as part of a
dovecot install then plugins could be distributed and built as independent
packages.  I quite understand that this additionally burdens dovecot
development with 'stable API' concerns which may not be considered worth
the effort.

Timo: have you thought about any of the above and if so which direction
have your thoughts taken you?

I can justify spending a small amount of time to develop this into real
code but it would be a waste to fight against or duplicate existing effort
that has gone into this area.  All comments welcome.

On Wed, 2007-02-07 at 16:21 +0000, pod wrote:
> My first thoughts were to simply move the dovecot-sieve code into the
> dovecot tree (I imagine under src/plugins/cmusieve or similar) and rework
> the autoconf setup as appropriate.  This sidesteps the problem for this
> case but does not help other 'third party' dovecot plugins.
I've been thinking that it should be possible to unpack tarballs under
some plugin directory and have configure automatically pick them up and
build them. But I'm guessing it'll be annoyingly difficult to implement
it with automake, so I haven't yet botherered to try.
> If however a simple plugin build environment were to exist as part of a
> dovecot install then plugins could be distributed and built as independent
> packages.  I quite understand that this additionally burdens dovecot
> development with 'stable API' concerns which may not be considered
worth
> the effort.
The 1.0.x series will have pretty stable API, but the problem I see with
this is that it'd either require creating some special simple and
limited plugin API (which I think is stupid), or including almost all
the .h files. The latter is possible though, the same thing is done with
irssi already in several distros. I guess there could be dovecot-dev
package containing all the .h files..

The reason why Sieve plugin wants .a files then is because it wants to
build standalone binaries as well. I'm not sure what could be done about
that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070215/5806a26a/attachment.bin>