>
>
> Jared Johnson wrote:
>>
>> > I think we should probably consider putting support for parsed
>> messages
>> > into core, with the parsing done lazily if requested by the API.
>>
>> I forgot, we did kinda think of a couple of reasons not to want an API.
>> depending on where you put it, you may find QP in general depending on
>> MIME::Parser even if it never uses it.  The benefit of the plugin is
>> that
>> /etc/qpsmtpd/plugins controls whether you wind up having to install, and
>> take up your memory with, MIME::Parser
>
> One thing we've discussed in the past (at least in my imagination)
> although not quite figured out how to implement, is making plugins act
> a little more like normal modules, so that one plugin can "use"
> another.
>
> So if you're interested in the "parsed mime" functionality, your
> plugin can "plugin_use util/parsed-mime" and the right magic happens.

Oh yeah that's right, someone *did* implement what you're talking about. 
You can do it with 'plugin inheritance' (which ironically i knew nothing
about until looking at the async uribl plugin the other night):

# /usr/share/qpsmtpd/plugins/mime_parser
use MIME::Parser;
sub parse_mime {
    my ( $self, $txn ) = @_;
    return $txn->notes('mime_body') if $txn->notes('mime_body');
    .... a bunch of code to create a $msg ...
    $txn->notes( mime_body => $msg );
    return $txn->notes('mime_body');
}

# /usr/share/qpstmpd/plugins/some_plugin_that_might_want_mime_parsing
sub init {
    my ( $self, $qp, %args ) = @_;
    return unless $qp->config('parse_mime') or $args{parse_mime};
    $self->isa('mime_parser');
    $self->{can_parse_mime} = 1;
}

sub hook_data_post {
    my ( $self, $txn ) = @_;
    if ( $self->{can_parse_mime} ) {
        $self->some_recursive_mime_function( $self->parse_mime );
    } else {
        $self->regular_body_getline_function( $txn );
    }
}


Voila!  A lazy 'plugin model' that is *also* and API, which doesn't 'use
MIME::Parser' until you *want* to use it; furthermore, you don't have to
just put the official mime_parser plugin in there, with a little
modification (or alternatively some care to use the same filename within
an alternate directory) you could use your home-rolled
messier-but-more-efficient version that doesn't use MIME::Parser at all.

I could easily modify my own stuff to do this and test it.  I'd even be
interested in pulling a couple of our own home-grown MIME recursion
methods into it.  If this is indeed the will of the council ;)

p.s. I'm kind of stoke about plugin inheritance these days.  I'm becoming
convinced that after some code churn on our side it will allow us to
finally switch to async without having to do just rewrite all our plugins,
switch to the async daemon, and see what happens.  And with a little churn
on the upstream side, if that manages to happen, I also think it could
allow us to un-fork 90% of the QP plugin code we currently have re-written
and instead submit patches to QP that have some guarantee to be tested and
aren't surrounded by completely useless context :)

-Jared

Reply via email to