> > 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
>
> See in my mind, per-recipient config and persistent data storage are more
> separate. Maybe part of the reason I look at it this way is that in my
> own implementation, I never really write "config" for a recipient, I only
> read it (from my persistent storage, the db, of course). I don't see i
> so inside QP, the qpsmtpd::address object would have a known parameter
> that brings up the per-address persistence hash, which would be a flat
> hash. Something like
..
See in my mind, per-recipient config and persistent data storage are more
separate. Maybe part of the reason I look at it thi
On Wed, Jul 28, 2010 at 2:35 PM, David Nicol wrote:
> On Wed, Jul 28, 2010 at 2:14 PM, Jared Johnson wrote:
>> I think we've had a thread about this before, but how do you see the API
>> for a standard hook for persistence working?
>
> either the tie or overload interface is invoked by the plug-i
>> Also: we recently contributed a new URIBL plugin to the Qpsmtpd
>> project,
>> which makes use of our "pruned TLD" lists that use your datafeed data.
>> They had some question of whether this was something you would be
>> comfortable with having distributed publicly. Note no actual URIBL data
>
>
> 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
