[Dovecot] "pipe" plugin - is anyone interested (or using it)?
johannes at sipsolutions.net
Sat Dec 8 00:38:51 EET 2007
> It certainly is a matter of taste, but that also was the reason why I
> did not like your plugin... ;-)
Aha, but with what I proposed that becomes a matter of configuration,
hence my SPAM>* rule in there.
> Lastly, I'd prefer my user to make some explicit action to learn a
> message rather than have a system that somewhat "guesses" for them...
You can still have that, I was just expressing how my plugin works in
terms of some "rules".
> > I do think, however, that the two plugins could possibly converge.
> I don't think they can converge, they work in very different ways,
> since yours work at the IMAP level while mine works at the storage
Actually, I work at storage level too now, I modified it.
> Hence, mine can also be triggered by a delivery with dovecot's
> deliver, but when a message is copied or appended, it does not know
> where it comes from (but as far as I am concerned, since I don't like
> triggering when moving a message out of a folder, it does not matter).
Yeah, if you load it into deliver which I'd consider somewhat stupid to
do with my plugin.
> Those only work if you consider messages that are copied from a folder
> to a different one. But how do you deal with messages that are
> appended from another source (such as messages being delivered or
> appended by an IMAP client)?
Good point. You could treat that as the "empty" source, like
pipe.3 = >SPAM do something
and have a wildcard that matches all (like .* RE) and one that matches
"all not empty" (like .+ RE)
> It looks to me that you only consider spam/ham learning as a use for
> such a plugin. I think other uses are possible. For example, I
> remember someone who was willing to implement an outbox.
No, but I'm using spam as an example of how your plugin could be
generalised to work the same as mine with a different configuration. It
seems to me that you only consider use cases that depend on the target
folder while my generalisation was to make it depend on the pair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 828 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20071207/739e0822/attachment-0001.bin
More information about the dovecot