On Jul 25, 2010, at 2:43, Jared Johnson wrote:
> it will soon be hopelessly forked from normal QP on account of
> per-recipient config directives, etc.
Having a common API for "per-recipient" things have long been on the todo list.
We've talked about it a couple times before; but the requireme
> Having a common API for "per-recipient" things have long been on the todo
> list.
>
> We've talked about it a couple times before; but the
> requirements/needs/wishes never sunk in deep enough in my head to do
> anything about it. So: How do you use this?
>
> My thoughts all along have been to
> sub rejected_recipients {
> my $self = shift;
> @_ and $self->{_rejected_recipients} = [...@_];
I noticed after posting this that the line above is a no-op. Ha :)
> return () unless $self->{_recipients};
> return grep { $_->dsn and ! $_->dsn->action ~~ [qw(Delivered Queued
> Quarantine
On Mon, Jul 26, 2010 at 10:27 PM, Ask Bjørn Hansen wrote:
>
> On Jul 25, 2010, at 2:43, Jared Johnson wrote:
>
>> it will soon be hopelessly forked from normal QP on account of
>> per-recipient config directives, etc.
>
>
> Having a common API for "per-recipient" things have long been on the todo
> My experience porting the Advenge SMTPD to be a qpsmtpd plug-in
> indicated that the current interface is entirely adequate for
> per-recipient things, as long as the plug-in manages its own
> persistence. I don't think any new hooks are required.
On principal I'd agree that it's possible to do
I assume you meant to CC the list originally, I've added it :)
>> Could you show some code examples?
>
> not immediately, but sure
>
>> What do you do with the queue
>> plugin(s) if recipients ended up having different headers or bodies due
>> to
>> tagging etc.?
>
> Advenge only deals with delive
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
> 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
> 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
> I have stuff that might wind up looking like
>
> $rcpt->persistent->{statistics_receivedmsgs_total}++;
>
> $rcpt->persistent->{statistics_receivedstatsbysender}{$NormalizedSenderAddress}++;
Perhaps $rcpt->storage could be provided that could be tied... it just
seems like this is the
> colleagues have also complained that notes() even exists as a method and
> think it would be fine for it to just be a reserved namespace accessed
> directly as a hash key.
or at least that notes() should return the {_notes} hashref if it doesn't
have any callers
-Jared
On Thu, Jul 29, 2010 at 11:48 AM, Jared Johnson wrote:
> Nothing's exactly stopping you from
Another thing that nothing stops us from, in a late-bound programming
language without private namespaces, is adding additional methods to
base objects without changing the code that declares the base o
> Another thing that nothing stops us from, in a late-bound programming
> language without private namespaces, is adding additional methods to
> base objects without changing the code that declares the base objects,
> as long as the implementation of the base objects promises to remain
> the same.
13 matches
Mail list logo
