[Dovecot] considering dovecot

[Mark E. Mallett]

On Wed, Nov 29, 2006 at 10:38:16PM +0200, Timo Sirainen wrote:
> On Wed, 2006-11-29 at 12:47 -0500, Mark E. Mallett wrote:
> > My own MDA (which I haven't plugged here lately :) but which I do use
> > with dovecot)
> 
> Have you tried if you could plug it into Dovecot's deliver as a
> replacement plugin to CMU sieve?

No, but that might be an interesting experiment.  I *have* looked over
the interface between dovecot lda and libsieve.


> I'd like to get an alternative to it,
> but I don't really want to spend time coding yet another Sieve
> implementation. And last I checked, your code wasn't exactly
> library/plugin-friendly at least to my eyes.. :)

You're right there, but I don't think it would take much to make
it so.  I have "plugged" mfl (the language) into multiple applications,
but those have been written with using the language in mind from
the beginning.

I see only a few obstacles to making it more generically usable (most of
you can probably hit delete now...):

 - mfl/sieve code makes calls to specifically-named functions to do
   actions (like "fileinto" etc).  These could fairly easily be turned
   into callbacks or calls via function pointers.

 - mfl code thinks it knows how messages are stored in memory, and makes
   some direct use of structure elements; it also makes calls to
   specifically-named functions to access things like headers and mime
   parts.  These things could also be turned into callbacks.

 - mfl code makes use of a bunch of my own suite of utility functions,
   which would have to be added to the library references.  Undoubtedly
   some of these utility functions duplicate those in your application
   (or any that would want to use it), so it would add some size to the
   executable.  It also creates another library dependancy to be figured
   out at configure time.  Neither of those are all that big of a deal,
   but they might offend some purist nature.

I dunno, maybe I'll give it a shot, e.g. over the upcoming holiday.
I've been thinking about trying to make the mfl piece more standalone
anyway: the main downside being that it creates yet another library
piece to maintain and for users to download.

mm