> As you mention the moon - is there any interest in embedding ...
> my-favorite-scripting-language... in exim?
Since I am just a lowly exim consumer, it's presumptuous of me to
suggest to someone else how to spend their time. But here I go anyhow!
:-)
I have three related things to say....
1. Years ago, I used to use the embedded perl for a few things. I only
felt that I could afford that because I was a low volume site, and using
perl to do fairly simple things was a tolerable overkill. It so happens
that various improvements in exim and elsewhere made it possible for me
to get rid of my perl callout and do everything in exim native
configuration. Personally, I would mostly strongly avoid going back to
these kinds of callouts, even if they were available for
my-favorite-scripting-language. Here are some of the my reasons, which
may or may not matter to any given one of you reading this:
-- Don't confuse easy-to-code with easy-on-my-machine. Many scripting
environments have pretty surprising costs in memory or CPU or both. You
probably don't notice that when you do things from the command line
because the machines are so fast (a prerequisite to their eventual
takeover plan :-). But exim is a server process, and resource costs
matter at scale. Scripts can be pretty great as wrappers, but I stay
away from them as things being wrapped (and I go all the way back to
having embedded the first releases of TCL in some production code).
-- I currently get away with using my distro's exim package (which has
been very prompt on providing security updates for its packages). I
used to build exim from sources. Not being a "perl guy", the perl part
would go wonky about half the time for me, and I'd have to spend an hour
or two trying to remember what I'd done last time around. Just another
brick on the load. I don't really want to have to worry about whether
the pre-built image has the external scripting I need or whether I have
to take on building it myself. (Truth be told, this is the factor that
made me get rid of my perl callout.)
-- I have benefited greatly over the years from little config fragments
and helpful tips from other exim folks. One of the toughest times I had
was making use of a not-quite-correct-and-current perl callout. (Again,
I'm not a "perl guy".) That sort of problem would only get worse for me
if I started seeing "look ... you can do this in a single line of
Crabapple scripting as long as your system has the Plumbob extension
already installed". When I see tips in exim native configuration, I
know all I have to worry about in my environment is that I have a recent
enough exim version (and the answer is almost always yes). (That's
right ... I'm saying that it would make things easier for me at the
possible expense of making it harder for you. Life can be so cruel. :-)
2. There are a small number of things that exim native configuration is
missing that would go a long, long way to either making a lot of other
things possible or at least making it possible do things that you could
read and understand later. If we had these things in a way that had a
familiar usability, the desire for scripting might be diminished quite a
bit:
-- Functions have already been mentioned. (This does risk just
inventing a new scripting language that might bring along some problems
mentioned above.)
-- I countered that a macro facility with parameter substitution might
get a lot of mileage. I already make extensive use of the current macro
facility just to try to keep up with the ungainly things I've
constructed, but it's still a bit of a train wreck. Substitutions would
help a lot.
-- Assigning and updating variables outside of ACLs. The custom acl_c_
and acl_m_ stuff is fantastic. I just wish I could do it in my
routers. As far as I can tell, the only thing you can do is build up
fairly complicated lookup strings in the single address_data variable.
That is just an unending parade of special cases and text parsing
trouble. What I wouldn't give for a "set" feature something like that
available in ACLs. (The stuff I need is mostly per-recipient (acl_r_ ?)
as I traverse routers in multiple passes, but I could see per-message
and per-connection.) This is far and away the thing I wish for the most.
3. If someone does go to the trouble of looking into how to integrate
more scripting engines, I hope it will be kind of a general SPI. (Maybe
exim already has that with shared libraries ... I don't follow it
closely.) When the Java folks decided to make scripting callouts a core
feature, they developed it as a plug-in SPI so that anybody with the
inclination could add a scripting engine to the environment and use it
without needing to change anything other than their own code. The
details for exim would certainly be different, but it's a good model.
