New thread:
Ask Bjørn Hansen wrote:
1) I'm going to do 'X';
2) I'm doing 'X';
3) I just did 'X'.
I like that! That'll take care of at least some of the need for
defining the hooks as running FIRST, MIDDLE and LAST too.
I was thinking that it should be made clear that the _pre and _post
hooks are slightly different than the cases that "FIRST, MIDDLE and
LAST" variants are likely to cover.
For example (this is open for discussion):
====================================
[hook]_pre - fires immediately before [hook] and can be used to avoid
running [hook] entirely. Only return values of OK, DONE, and DECLINED
are acceptable. OK means fire [hook] and DONE means skip the [hook]
processing entirely. DECLINED has its ordinary meaning in that multiple
hooks can return it and if none of them returns OK, then the normal
[hook] processing continues. NOTE that DONE may be meaningless for
certain hooks, e.g. DATA *must* be processed.
[hook]_post - fires immediately after [hook] iff [hook] returned either
OK or DECLINED (but not any variant on DENY). Return values of OK,
DECLINED, or DENY (plus variants) are acceptable. If DENY (or a
variant) is returned, then this will be promoted to returning this value
from [hook] (e.g. block viruses in data_post).
Both _pre and _post variants *should not* perform the actions normally
performed by the associated hook. That includes (but is not limited to):
- reading from the remote client
- responding to the remote client
Both _pre and _post hooks *may* modify the in-process transaction object
(e.g. adding headers).
====================================
The _pre and _post hooks will normally be implemented inside the sub()
for the associated hook, so that the current flow control will not be
altered (e.g. data calls data_pre, does its shtick, then calls queue,
and finally calls data_post).
John
