On 31-Mar-08, at 10:12 AM, John Peacock wrote:
Matt Sergeant wrote:
Because otherwise hooks are re-loaded on every connection (register
() needs re-run on every mail) which is a huge performance detriment.
Then we need to rethink that architecture; would it be acceptable
to return immediately if hooks are already defined (instead of just
warning and redefining)? That was the original plan, but it may
have been messed up over time.
No I don't think it would be acceptable. It's just way too much
overhead to run on every connection (it was one of the highest items
in my profiling).
I don't think per-object hooks ever worked right or were useful
anyway were they?
The problem was that some parts of the codebase still assumed per-
object hooks, which is why auth was not working correctly.
But there's a patch in this thread to fix that, right?
If you want to go that route, you'd need to go through and find all
$self->{hooks} and replace them with $self->hooks() like Hanno
suggested, but also have a setter for actually registering the
hooks. It also means that the hooks listing is only available
inside the Qpsmtpd:: scope itself, and I haven't checked where else
that was accessed in the core code.
Changing %hooks to an "our" makes that work though.
My long-term goal was to write a generic RFC-2822 event loop that
could be extended at both load and run time, rather than having
some phases in core and some as hooks (think of how auth and TLS
are currently manhandled into the core, the latter by hooking
unrecognized commands). This would mean each transaction might
have a base set of phases/hooks (to correspond to the bare EHLO/
FROM/TO/DATA/QUIT set), and based on what was registered at load
time, would gain additional phases/hooks inbetween. Specific
plugins would also be able to add hooks (like greylisting or
tiergrube) in a Just In Time model per transaction.
I still don't quite understand why AUTH wasn't implemented as an
unrecognised command hook... I'm sure it would have been possible, no?
Matt.
