Matt Sergeant wrote:
Hmm. That is complicated. Might be made simpler now I broke run_hooks
down into run_hooks + run_hook (see high_perf until I get that checked
in), but that still seems the wrong approach. The right approach is to
be able to arbitrarily add hooks (heck, we might want all sorts of other
hooks for things like "hook_ssl_cert" or something).
My concern isn't for being able to add user-defined hooks, per se, but
rather to make sure that run_hooks() be run on that new hook in an
appropriate fashion. I don't like plugins being able to register random
hooks without some way of controlling when those hooks actually get called.
In my mind, every (E)SMTP keyword should automatically be supported in
the core and have a sub that does if nothing else just
run_hooks("keyword"...). If nothing is registered for that hook, so
what, we spent a dispatch. Then there should be hooks corresponding to
the transitions between phases in the (E)SMTP transaction (that don't
already have a keyword, i.e. connect). And in fact, there should
probably be a before_ and after_ variant for each of those (e.g. an
after_DATA hook). And finally, we need a hook reordering scheme, so
plugins could request hooks run FIRST, LAST, or MIDDLE.
With all of that structure in place, I don't see any way that we
couldn't deal with all the needs plugins would have.
John
p.s. of course, we could provide a way to hook the custom hook to other
hooks, so when you register a new hook, you would also specify which
hook would fire your hook...
