On 8 Jul 2005, at 14:09, John Peacock wrote:
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.
All rather scary. As a starter to all that, I propose we get rid of
SMTP.pm keeping a list of known SMTP verbs and instead just rely on
$self->can("cmd_$meth"). That way you can easily inject things into the
SMTP.pm namespace.
Matt.
