Re: Rewritten URIBL plugin

> > 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):

You do know who that someone was, right? ;)

<snip>

> 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.

Nice.  That does work out to be a nice bit of code reuse.  The
syntactic sugar is.. well..  lacking, but that's ok.  It's
understandable!

> 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 ;)

I like it.  But I'm just one person.

> 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 :)

Nice.

-R