On Tue, 4 Jan 2005, Marilyn Davis wrote:
>
> I just unscrambled the order on all my routers to match the testing
> order. I wonder if you have some other suggestions -- for the
> non-testing statements?
At the moment my style guide says to order router statements as in the
list below. I've put a couple of examples in each section to give an idea
of what goes where. It's still a bit experimental:
Successes:
ordering of preconditions
ordering of transport options
keeping transport-related things to the end
the quick reference for expansion and default values
Failures:
At the moment I don't separate the router options into sections in
my configuration file, so between the preconditions and the
transport options the reason for the ordering becomes unclear.
For example, it might be clearer for the per-driver "other"
options to go before the subsequent routing options.
I haven't kept the style guide up-to-date or reviewed it in the
light of experience.
I think I posted it to the list shortly after writing it originally, but
Google only finds the copy on my web site:
http://www.cus.cam.ac.uk/~fanf2/hermes/doc/misc/EximStyle
# mandatory option
driver (examples from the redirect router)
# any preconditions in the order they are tested
# (see section 3.11 of spec)
domains
condition
# generic options that can control how the router accepts
address_data
ignore_target_hosts
# per-driver acceptance options
data
skip_syntax_errors
# options that control subsequent routing
more
unseen
# per-driver subsequent routing options
check_ancestor
# other options
cannot_route_message
# other per-driver options
allow_fail
forbid_file
# ordered transport-related options
# (see start of section 15 of spec)
errors_to
transport
# per-driver transport options
pipe_transport
# other transport-related options
fallback_hosts
initgroups
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}