* Joachim Schrod <[EMAIL PROTECTED]> [2007-05-07T13:09:49] > The description page for Email::Filter itself is sparse, to say the > least. For Mail::Audit, at least some future plans are written down; > no such information about Email::Filter. (E.g., what about missing > functionality for migration from Mail::Audit, or a substitute for > Mail::Audit's procmail migration support).
The situation is something like this: * I am a big loser, and still haven't quite converted my own mail filtering from procmail to Perl. (Instead, I've written a lot of Perl to generate my procmail configuration.) * Where I work, we use some long-established code that uses Mail::Audit. This means that I have a pretty strong incentive to work on Mail::Audit, and less to work on Email::Filter. This is too bad, because Mail::Audit is definitely the crazier code. > As a further example, let's take this open bug ticket: > http://rt.cpan.org/Public/Bug/Display.html?id=25027 > Does this really mean that it is hard to migrate the logging > component of one's Mail::Audit setup? Yes, probably. Email::Filter is really very minimal. It doesn't have logging built in, so it would need to be added by a plugin. Unfortunately, the existing triggers are not well-documented, and they're very minimal and could use enhancement. (I have often found that the Email:: code is nice and simple, but usually just a little too simple for me to /use/; I try to add the needed stuff without compromising the simplicity.) For that logging bug, there's an ideal place to add a trigger, but there's no way to get the needed data. > But anyhow, as I wrote: I have a working setup with Mail::Audit, and > that module is listed in PEPMaintained, so I thought it is a > maintained PEP module. Nevertheless I consider a switch, if that is > considered best-practice and if somebody could please explain why it > is best practice, could point out some advantages of the new module. If I were you, I would stick with what works. If you have some tuits, it would be great if you wanted to help make Email::Filter more pluggable, and then port yourself. I just don't think you need to switch if it isn't broken for ou. > Thus I'll repeat my questions: > -- Is Email::Filter faster? Probably. > -- Maybe its code quality is better: > -- Has it fewer known errors? I don't think so, but only because you said "known." The M::A code is a mess. The Email::Filter code is very simple. > -- Or is it bug history better, fewer bugs over time? > -- Maybe it is known to abort more seldom? > -- Or is it otherwise more stable? How? Email::Filter seems (based on my gut) so much less used that it's hard to say. Its bugs tend to be, "why can't I easily X?" while Mail::Audit's bugs tend to be "why does X fail in this weird way under these circumstances?" > -- Is its memory footprint smaller? Almost certainly. > -- Are there plans about future features that will be easier to > uptake if I switch now? I have no plans for it, specifically. Yet. > -- In particular, better SpamAssassin integration than the two > lines of obvious code from Email::Filter::SpamAssassin? In my own prototype of an Email::Filter script for myself, I used my Mail::SpamAssassin::SimpleClient. I agree that SA needs to be way, way easier to use from E::F. > One or two (or more :-) of such advantages would be a very good > incentive for the additional work that needs to be spent migrating a > working installation. Maybe, not only for me; this could be something > for the PEP Wiki. (And if some folks would answer these questions, I'm > willing to spend the time to add a summary of the answers to the > Wiki.) Yeah, I need to get better at adding "to do" items to the wiki, so that volunteers or knowledge-seekers can more easily see what's done and what isn't. -- rjbs
