lmjm@??? said:
} My suggestion a few days ago was to add the ability to filter a
} message through an external program. This could be used to do all you
} ask. It is also more general than hardwiring in perl, as has been
} suggested. Personally I like perl but it would be a shame to lock
} people in to perl as a scripting language when it isn't necessary.
Lee,
Your suggestion has the advantages of simplicity and generality. It would
certainly be generally worth doing (maybe just as a filter call out - ie
add a filter method to call out to something), and a good definition of
the interface (is this a EGI - like the www CGI, but Exim Gateway
Interface).
The easy way of doing this is to shove pretty much all the exim internal
variables into environment variables (since this can be seen from outside
the process is this a security risk - or at least a risk to worry about),
and take a formatted message from stdout. [The alternative I guess is to
shove everything into a temp file and pass that across].
The real kicker for me is the performance. Our core boxes currently shift
a few hundred thousand messages per day. An extra fork/exec would be
painful. A fork/exec of a perl program would be *very* painful unless I
could precompile it (which admittedly is just around the corner for
serious use). The perl builtin would allow much higher performance and
probably be easier to extend for "more interesting".
However since this is really precisely parallelling the web server debate
of a year or 2 back we should look at building on their solutions:-
1. Embedded specific language. What we have now. Endless game of catch
up
to add features. Tends to be a rather inefficient
compiler/interpreter
since another wheel has been invented, but is fast because there is no
extra process involved and so the inefficiencies are hidden.
[examples - current exim filter, www php extension language]
2. External server process, method of calling this up with reasonable
efficiency.
A good API allows all sorts of external code to be used. A bit
complex,
debugging can be tricky. Nice separation between server code and the
add
ons. [examples are Fast CGI - bindings for perl, tcl, c]
3. Embedded language. Good generally developed language add on. Often
very
good efficiency. You can get at the server guts (this is both good
and bad).
[examples mod_perl for Apache and tcl equiv, also done for inn]
Nigel.
--
[ Nigel.Metheringham@??? - Systems Software Engineer ]
[ Tel : +44 113 251 6012 Fax : +44 113 234 6065 ]
[ Real life is but a pale imitation of a Dilbert strip ]
--
*** Exim information can be found at
http://www.exim.org/ ***
