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